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.
  • 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.
  • ...
Maiores informações sobre o Servidor SOAP podem ser obtidas diretamente em [2] ou [1].

[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/.

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/.

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.




Figura 1. Rede Ad hoc com Serviços Disponíveis


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

[1] Halonem, Tommi; Ojala, Timo. “Cross-Layer Design for Providing Service Oriented Architecture in a Mobile Ad hoc Network”.

sábado, 19 de janeiro de 2008

SOA para suporte em Dispositivos Móveis

An Open and Dynamical Service Oriented Architecture for Supporting Mobile Services

Neste trabalho Sánchez-Nielsen et al [1], propõe uma arquitetura orientada a serviços para suporte a dispositivos móveis. Neste contexto, os autores propõe uma arquitetura que atenda aos seguintes requisitos: serviço orientou arquitetura que se dirige os assuntos seguintes: (1) integração dinâmica de novos serviços por provedores, (2) descoberta dinâmica de serviços disponíveis e (3) o uso de um software de fonte aberto para desenvolver o solução.

Basicamente a arquitetura proposta se divide em quatro componentes principais: (1) provedores de serviço, (2) o gerenciador de serviços, (3) os clientes e (4) o registro de UDDI. A Figura 1 apresenta o modelo da arquitetura proposta pelos autores.

Figura 1. Arquitetura SOA para Dispositivos Móveis

Os principais componentes da arquitetura são descritos a seguir:

· Provedores de Serviço: são os principais components que implementam e oferecem os services disponíveis. Estes serviços são descritos utilizando a liguagem WSDL.

· Clientes: representam os usuários de dispositivos móveis que estão interessados nos serviços disponíveis no ambiente em que ele se encontra, estes serviços devem ser fornecidos aos clientes de uma forma transparente para si.

· Gerenciador de Serviço: é a camada intermediária entre os dispositivos móveis e o provedor de serviços. É o responsável pelo fluxo das informações entre ambos os componentes. Um gerenciador de serviços é um web service que utiliza uma invocação dinâmica de serviços como mecanismo de comunicação entre os diferentes provedores de serviços.

· Registro UDDI: estes registros são utilizados para a localização de novos serviços. A descoberta de serviços é computada em tempo de execução pelo gerenciador de serviços, quando o usuário envia uma requisição de um novo serviço.


[1] Sánchez-Nielsen, Elena; Martín-Ruiz, Sandra; Rodríguez-Pedrianes, Jorge. “An Open and Dynamical Service Oriented Architecture for Supporting Mobile Services”, In: ICWE - International Conference on Web Engineering. Palo Alto, EUA. 2006

quinta-feira, 17 de janeiro de 2008

Especificações OMA (Open Mobile Alliance)

OMA (Open Mobile Alliance) é uma organização criada em junho de 2002 focada em especificação e definição de padrões abertos para dispositivos móveis. Ela nasceu de uma iniciativa de alguns fóruns (Wireless Village Forum, WAP Forum, Location Interoperability Forum, Mobile Games Forum e Mobile Wireless Internet Forum) que discutem sobre temas relacionados a mobilidade. Nestas discussões são criadas soluções e especificações que muitas vezes representavam esforços repetidos. Assim nasceu a OMA que tem por objetivo centralizar todas as especificações padrões das arquiteturas para dispositivos móveis discutidas nos fóruns associados e também os fornecidos pelas empresas associadas, que compreendem grandes empresas do mercado de dispositivos móveis.

A maior contribuição desta organização é o número de especificações desenvolvidas em conjunto com seus parceiros, as quais endereçam grande parte dos problemas encontrados nos desenvolvimentos de dispositivos móveis. Estas especificações muitas vezes apresentam o problema e as possíveis alternativas sem determinar a solução, apesar de mostrarem o estado da arte, as técnicas existentes e o direcionamento dos estudos. A lista de especificações para dispositivos móveis é bastante ampla, como demonstrado abaixo:

  • Billing Framework
  • Browsing
  • Browser Protocol Stack
  • Charging
  • Client Provisioning
  • Client Side Content Screening Framework
  • Data Synchronization
  • Device Management
  • Digital Rights Management
  • Domain Name System
  • Download over the Air
  • Email Notification
  • External Functionality Interface
  • Firmware Update Management Object
  • Games Services
  • Games Services Client Server Interface
  • Instant Messaging and Presence Service
  • IP Multimedia Subsystem
  • Mobile Broadcast Services
  • Mobile Location Protocol
  • Mobile Location Service
  • Multimedia Messaging Service
  • On-Board Key Generation
  • Online Certificate Status Protocol Mobile Profile
  • Presence Simple
  • Push
  • Push to talk over Cellular
  • Secure User Plane for Location
  • Smartcard Web Server
  • SyncML Common Specification
  • Standard Transcoding Interface
  • URI Schemes
  • User Agent Profile
  • vObject Minimum Interoperability Profile
  • Web Services
  • Web Services Network Identity
  • Wireless Public Key Infrastructure
  • XML Document Management
  • Maintenance of Requirements for Privacy for Mobile Services
  • Messaging Services Interworking
  • Mobile Gaming Evolution
  • Parlay/OSA in OSE
  • Service Environment
  • SyncML Primer
  • UAProf Best Practices Guide

Como exemplo destas especificações temos o padrão de orquestração para dispositivos móveis [1] como apresentado num típico exemplo de pattern de orquestração.

Figura 1: Pattern de orquestração [1]

Descrição:

O pattern de orquestração oferece uma interface de serviço de composição desenvolvido para coordenar um conjunto de web services individuais. Requisitantes vêem o serviço composto, não os serviços individualmente, porque isto é uma interface de composição de serviço que é publicada externamente. Na figura 1 o WSR (Requisitante) interage com outro web services, WSs 1, 2 e 3, neste exemplo, e possivelmente outros sistemas não mostrados na figura. Um orquestrador tipicamente acrescenta lógica além de meramente orquestrar requisições individuais de componentes de serviços.

Problema endereçado:

É possível fornecer um novo Web Service que é uma composição de dois ou mais Web Services?

Ponto de vista do WSR.

  • É necessário incluir toda informação na mensagem de requisição de Web Service – em particular, informação adicional tais como credenciais, asserções, etc, - que é necessário para o processamento bem sucedido da requisição;
  • Para o WSR, o orquestrador é o WS. Ele não sabe sobre o serviço de composição, ou como o WS fornece esta função;

Ponto de vista do componente WS

  • Ele pode oferecer uma simples interface para seu núcleo de funções e executar uma parte em um serviço de composição maior. (Entretanto ele muito provavelmente não sabe se ele é usado em um serviço de composição);
  • A requisição é recebida de um orquestrador no mesmo domínio de confiança, ele poderia seguramente assumir que a requisição foi autenticada apropriadamente e autorizada;
  • Do ponto de vista do componente WS, o orquestrador é o WSR para este serviço;
  • Os componentes WSs são descobertos pelo orquestrador, no geral;
Ponto de vista do Orquestrador:
  • Ele executa a lógica de negócio para satisfazer a composição do Web Service, fornecendo uma seqüência de chamadas de Web Services separadas e agregando o resultado destas para atingir determinadas funcionalidades;
  • O orquestrador deveria publicar o novo serviço resultante da composição em um registro de serviço externo;
  • O orquestrador deveria fornecer uma lógica de manipulação de falhas e erros gerados pelos serviços individuais;

Implicações:

  • O mesmo (componente) WS poderia ser parte de um ou mais serviços de orquestração;
  • Note que alguns dos componentes WSs poderiam manipular funções tais como integridade, autenticação, etc.;
  • O serviço resultante da composição é tipicamente muito diferente que aquele oferecido pelos serviços de componentes;
  • Embora o componente WSs possam não estar conscientes do serviço global de que fazem parte, os seus serviços podem ser utilizados no âmbito de um contexto global transacional;
  • Como os componentes WSs podem ser reutilizados em muito serviços de orquestração, isto permite uma grande flexibilidade na criação de complexos serviços a partir de serviços simples;

O pattern de orquestração é um exemplo de definição que pode ser encontrado entre as especificações do grupo OMA. Existem outros temas relacionados a dispositivos móveis bastante pesquisados e ainda não resolvidos que são apresentados nas especificações, bem como, patterns alternativos e complementares a orquestração, tais como, routing, gateway, proxy, interceptor, adapter, delegate, filter, referral, sequence e workflow.

Tendo em vista, que grande parte das especificações disponibilizadas é resultado de discussões em fóruns e pesquisas dos associados, acredito que poderíamos encontrar gaps de tecnologia a ser pesquisada para dispositivos móveis ainda não preenchidas.

[1] Open mobile alliance group, OMA Web Services Enabler (OWSER): Overview - Version 1.0, http://www.openmobilealliance.org/release_program/owser_v10.html, Acessado em: Jan 2008.

quarta-feira, 16 de janeiro de 2008

kXML e kSOAP

Para qualquer iniciativa de tentar levar SOA para dispositivos menores, em ambiente Java, deve-se levar muito em consideração os parsers kXML e kSOAP. Eles parecem estar bem estáveis, já que desde 2006 nenhuma atualização foi feita e continuam aparecendo nos artigos científicos.

Portanto, um passo para Mobile SOA provavelmente passe pela dupla
kXML e kSOAP.


Sliver: Um Motor de Execução de Processos de Workflow BPEL para Dispositivos Móveis

Vou iniciar com a minha opinião. Aparentemente, esta arquitetura é muito parecida com o que estamos pensando para a "nossa" arquitetura. Vale a pena ler os artigos!

O projeto Sliver (http://mobilab.wustl.edu/projects/sliver/) se define como um motor de execução SOAP e BPEL para dispositivos móveis. Simplificadamente, o Sliver levou o BPEL de grandes servidores para pequenos dispositivos móveis, além da disponibilização de serviços, a criação de composições com eles. Importante salientar que o Sliver suporta muitos dos requisitos da computação pervasiva, tais como a questão de que os Web Services participantes de uma composição podem alterar seu status de online para offline e vice-versa diversas vezes. Ainda, permite a comunicação entre os serviços utilizando HTTP ou bluetooth, entre outros aspectos.

Segundo [1], Sliver é um motor de execução de processos de workflow BPEL que suporta uma grande variedade de dispositivos, desde telefones celulares até desktops. A arquitetura do motor de execução Sliver usa uma série de parsers escritos à mão desenvolvidos utilizando os leves pacotes kXML [3] e kSOAP [4].

“O desenvolvimento de motores de middleware como Sliver é um passo importante em direção ao objetivo de longo prazo de levar groupware para dispositivos móveis”. [1]



Como justificativas [2] para o projeto, no que diz respeito a aplicações de computação pervasiva, a incompatibilidade de arquiteturas de hardware e software está desencorajando interações ad-hoc entre os dispositivos. Ainda, o modelo de comunicação inflexível do BPEL efetivamente proíbe a sua utilização sobre os tipos de redes sem fio dinâmicas usadas pela maioria dos dispositivos de computação pervasivos. Por isso, propuseram extensões ao BPEL, implementadas no Sliver [1], que resolvem essas restrições, transformando o BPEL em uma plataforma versátil para aplicações computacionais pervasivas interoperáveis.

As três figuras abaixo ilustram o protótipo desenvolvido [2] como prova de conceito da arquitetura Sliver.







Maiores detalhes do Sliver podem ser encontrados em [1][2][5].

[1] Hackmann, G., Haitjema, M., Gill, C., and Roman, G.-C., “Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices,” Washington University, Department of Computer Science and Engineering, St. Louis, Missouri. (published in Proceedings of 4th International Conference on Service Oriented Computing (ICSOC 2006)) .
[2] Hackmann, G., Gill, C., and Roman, G.-C., “Extending BPEL for Interoperable Pervasive Computing,” Washington University, Department of Computer Science and Engineering, St. Louis, Missouri. (published in Proceedings of IEEE International Conference on Pervasive Services 2007 (ICPS 2007)).
[3] Haustein, S.: kXML 2. http:// kxml.sourceforge.net/ kxml2/ (2005).
[4] Haustein, S., Seigel, J.: kSOAP 2. http:// ksoap.org/ (2006).

[5] Hackmann, G., Haitjema, M., Gill, C., Roman, G.C.: Sliver: A BPEL workflow process execution engine for mobile devices. Technical Report WUCSE-06-37, Washington University, Department of Computer Science and Engineering (2006).

terça-feira, 15 de janeiro de 2008

Arquitetura SeSCO: Composição de Serviços em Ambientes Pervasivos

Seamless Service Composition (SeSCo) in Pervasive Environments

Neste artigo, Kalasapur et al. [1] apresentam uma arquitetura para composição de serviços em dispositivos móveis, esta arquitetura deve permite a execução de aplicações multimídias em ambientes heterogêneos, arquitetura denominada PICO pelos autores.
Basicamente os elementos que foram representados na arquitetura são os seguintes: (1) camileuns - representação abstrata dos dispositivos, (2) delegents - entidades de software que representam as características dos dispositivos como serviços, e (3) as comunidades - organização lógica de um número de delegents que trabalham para um objetivo comum, ou um serviço composto.
Para a arquitetura foram construídas funções de middleware fundamentais para a consciência de contexto. Porém, a consciência de contexto não estará ligada a uma infra-estrutura de software específica ou ambiente físico. A consciência de contexto estará disponível nos ambientes, através da transmissão em uma rede ad hoc, que contém as fontes de contexto e os consumidores. A Figura 1 apresenta o middleware construído para a arquitetura.


Figura 1. PICO middleware

O middleware para a arquitetura PICO é dividido em camadas, com operações diferentes que podem ser executadas em diferentes camadas do middleware. Baseado na capacidade dos dispositivos, podem haver três versões diferentes de execução, que essencialmente difere nas operações que eles podem executar. Para dispositivos com poucos recursos, pode ser instalada uma versão mínima do middleware, que contém uma pilha reduzida de instruções. Esta versão mínima é capaz de avisar e participar da descoberta de serviços, porém não é possível administrar tarefas mais complexas como orquestração e composição de serviços. A segunda versão, contém as mesmas operações da versão anterior, porém é instalado em dispositivos que são possivelmente móveis, como PDAs, laptops etc. A versão completa do middleware é instalada em dispositivos que possuem mais recursos, como PCs, servidores. Estes dispositivos podem executar tarefas mais complexas como descoberta e composição de serviços.
O foco dos autores no trabalho está relacionado a camada de serviços, a Figura 6 apresenta os componentes que compõem a camada de serviços desenvolvida, esta figura detalha a camada de serviços representada no middleware da Figura 2. A camada de serviços do middleware é responsável por serviços básicos relacionados com as operações do sistema, como exposição do serviço, descoberta e composição.


Figura 2. Camada de Composição de Serviços


Conforme mostra a figura, o gerenciamento de publicação envia os serviços disponíveis periodicamente e também responde a publicações externas e pedidos. O serviço de agregação é responsável por armazenar os novos serviços que estão disponíveis. Já o serviço de composição é responsável por gerenciar a composição dos serviços e as informações pertinentes a cada serviço.
De uma forma simplificada os autores apresentaram uma arquitetura para a composição de serviços, principalmente a serviços inerentes a multimídia em ambientes ubíquo. Como a arquitetura envolve assuntos não relacionados com este trabalho, neste artigo foi apresentado o objetivo geral dos autores e um foco maior na composição de serviços, que está relacionado com o objetivo deste trabalho.

[1] KALASAPUR, Swaroop; KUMAR, Mohan; SHIRAZI, Behrooz. “Seamless Service Composition (SeSCo) in Pervasive Environments”, In: In: MSC - Multimedia service composition. Singapore. 2005.
Middleware for Multimedia Mobile Collaborative System

Os autores apresentam neste artigo [1], um middleware que visa facilitar a construção de sistemas colaborativos para dispositivos móveis focados em aplicações multimídia. São apresentados a arquitetura básica de um framework para auxílio na criação de sistemas colaborativos ubíquos. Inicialmente é exposto um framework conceitual para que suporte a criação de aplicações colaborativas para dispositivos móveis, a Figura 1 apresenta as camadas desenvolvidas para o framework.



Figura 1. Framework do Ambiente Colaborativo Móvel




Conforme mostra a figura o framework foi dividido em quatro componentes principais:
  • Camada de Geração de Conteúdo: nesta camada, o servidor de conteúdo gera o conteúdo baseado em uma requisição do cliente. A mensagem de requisição do cliente consiste no perfil do dispositivo, estado prévio da rede, e a URL solicitada. O servidor verifica a disponibilidade dos dados, se os dados estiverem disponíveis, o conteúdo será gerado e entregue ao cliente baseado no tipo do dispositivo que solicitou e a conexão de rede;

  • Camada de Comunicação: mantém em cada sessão a interação e entrega de mensagens entre o cliente e servidor. Descobre o estado da rede e decide se armazena as mensagens em filas para caso não exista conectividade da rede para seu posterior envio;

  • Camada de Consumo e Re-geração de Conteúdo: esta camada, as mensagens são combinadas e seus conteúdos enviados para a camada de visualização para exibição. Caso o cliente deseje fazer qualquer modificação no conteúdo, este será re-gerado. O conteúdo modificado pode ser enviado a um outro usuário diretamente ou ao servidor;

  • Camada de Visualização de Conteúdo: uma vez que o conteúdo chegue a camada de visualização, este objeto é transformado em uma estrutura DOM (Document Object Model), para então a utilização de um visualizador para apresentar o conteúdo disponibilizado.
De uma forma resumida, estas quatro camadas apresentadas fornecem suporte para busca e apresentação de conteúdo para ambientes heterogêneos. Ao se considerar a interação permitida aos usuários em páginas WEB, isso possibilita a colaboração e execução de sistemas complexos em dispositivos móveis, possibilitando a comunicação entre diferentes plataformas. A Figura 2 apresenta a arquitetura para um sistema colaborativo em dispositivos móveis construído a partir framework proposto.



Figura 2. Arquitetura de um Sistema Colaborativo Móvel

No protótipo desenvolvido o sistema permite a comunicação entre os membros de um grupo através de e-mail, chat ou mensagens de voz, e o compartilhamento de arquivos. Disponibilizando diferentes sistemas para os usuários a partir do middleware desenvolvido. Desta forma é apresentada a utilização da arquitetura proposta para a construção de sistema colaborativos para dispositivos móveis.
[1] SU, Xiaoyong; PRABHU, B. S.; CHU, Chi-Cheng; GADH, Rajit. “Middleware for Multimedia Mobile Collaborative System”, In: WTS – Wireless Telecomunications Symposium. California, EUA. 2004.

segunda-feira, 14 de janeiro de 2008

Arquitetura NMS (Nomadic Mobile Service) - Serviço de Dispositivo Móvel Nômade

Atualmente os dispositivos móveis estão dotados de uma série de características de comunicação, processamento e armazenamento que combinados com os últimos desenvolvimentos na área de SOA (Service Oriented Architecture) permitem o desenvolvimento de uma nova classe de serviços, chamada de NMS (Nomadic Mobile Services). Nomadic Mobile Service significa a extensão do paradigma SOA para dispositivos móveis possibilitando que estes disponibilizem serviços via Web [1]. Esses serviços permitem que um dispositivo móvel participe da descoberta de serviço na rede e forneça os serviços para os clientes localizados em qualquer lugar na Internet. Uma típica aplicação Nomadic Mobile Service é hospedada por um dispositivo móvel hospedeiro, tal como, um handheld, telefone celular ou qualquer tipo de dispositivo capaz de se conectar na Internet usando uma rede sem fio e, fornecer um serviço diretamente ou indiretamente como proxy. Esta capacidade de disponibilizar serviços de um dispositivo para outro de forma dinâmica é o que dá a característica de serviço nômade (Nomadic)

Os desafios encontrados no NMS estão diretamente relacionados com as características de mobilidade, acessibilidade e problemas encontrados em redes wireless. Estes problemas podem ser percebidos, por exemplo, nas baixas velocidades de transmissão, zonas sem cobertura e troca de ponto de acesso (sinal) quando em movimento.

Segundo [2], a maioria dos problemas encontrados nos serviços nômades (NMS) poderiam ser resolvidos essencialmente utilizando três técnicas de desenvolvimento:

  • Baseados em proxies em rede: são utilizados agentes inteligentes para o processo de controle das informações ou para manipular informações dos usuários que estão sendo trocadas entre o dispositivo móvel e um servidor de rede;
  • Aquisição judiciosa e cache de informações: Nesta abordagem são feitas pré-coletas e cache de dados de modo a permitir uma melhor performance;
  • Protocolos e aplicações assimétricas: Desenvolvimento das aplicações de forma assimétrica, onde informações, controles e serviços acessórios seriam executados previamente de modo concorrente;

Recentemente tem havido uma série de pesquisas com abordagens de soluções NMS que visam solucionar os problemas encontrados nesta arquitetura. Neste universo de pesquisas, [3] selecionou três estudos distintos que implementam as principais técnicas para resolver estes problemas:

  • NMS Proxy [4]: neste estudo é proposto um proxy baseado em um middleware sobre a arquitetura Jini surrogate [5];
  • NMS P2P [6]: neste estudo é apresentada a implementação de um protótipo de serviço web para celular que fornece e descobre serviços em uma rede peer to peer (P2P);
  • NMS Asymetric [7]: este estudo propõe uma infra-estrutura assimétrica chamada de Micro-Services capaz de hospedar web services em dispositivos móveis;

As arquiteturas NMS Proxy, NMS P2P e NMS Asymetric implementam distintamente as principais técnicas de desenvolvimento sugeridas por [2], as quais foram apresentadas anteriormente. Abaixo segue uma visualização em alto nível destas arquiteturas:

Figura 1: Visualização em alto nível das arquiteturas NMS [3].

O estudo destas implementações e das características encontradas nestas arquiteturas permitiu o desenvolvimento de uma tabela comparativa com as diferentes abordagens pesquisadas, como demonstrado abaixo:

Tabela 1: Escolhas de Desenvolvimento NMS [3].

Como pode-se perceber as pesquisas de soluções NMS estão evoluindo e os principais questionamentos estão sendo endereçados, porém existem muitas questões ainda por serem resolvidas, tais como, QoS e orquestração de serviços.

Maiores detalhes sobre NMS podem ser encontrados em:

[1] Halteren, A.v. and Pawar P., Mobile Service Platform: A Middleware for Nomadic Mobile Service Provisioning. 2nd IEEE International Conference On Wireless and Mobile Computing, Networking and Communications (WiMob 2006), Montreal, Canada, June 2006.

[2] La Porta, T. F., Sabnani, K. K., Gitlin, R. D., Challenges for Nomadic Computing: Mobility Management and Wireless Communications. Mobile Networks and Applications, 1(1): p. 3-16, 1996.

[3] Pawar, P. and van Beijnum, B.J.F. and Srirama, S. and van Halteren, A.T. (2007) A Comparative Study of Nomadic Mobile Service Provisioning Approaches. In: Proceedings of The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies, 2007. NGMAST '07., 12-14 Sep 2007, Cardiff, UK. pp. 277-286. IEEE Computer Society. ISBN 0-7695-2878-3/07

[4] Halteren, A.v. and Pawar P., Mobile Service Platform: A Middleware for Nomadic Mobile Service Provisioning. 2nd IEEE International Conference On Wireless and Mobile Computing, Networking and Communications (WiMob 2006), Montreal, Canada, June 2006

[5] Sun Microsystems, Jini Technology Surrogate Architecture Specification. https://surrogate.dev.java.net/doc/sa.pdf, October 2003.

[6] Srirama, S.N., Jarke, M. and Prinz, W., Mobile WebService Provisioning. International Conference on Internet and Web Applications and Services (ICIW'06), Guadeloupe, French Caribbean, 2006.

[7] Pratistha, D., Nicoloudis, N. and Cuce, S., A Micro-Services Framework on Mobile Devices. International Conference on Web Services, Nevada, USA, 2003.

sábado, 12 de janeiro de 2008

Arquitetura Mobile Host

A arquitetura Mobile Host [1][2] apresenta uma abordagem para o fornecimento Web Services móveis. Em seus estudos, os desafios chave encontrados foram:
  • Manter os Web Services compatíveis de tal forma que os clientes não notassem a diferença.
  • Projetar o hospedeiro móvel com uma pequena parcela dos recursos disponíveis em um dispositivo móvel (em seu protótipo, 130 KB).
  • Limitar a sobrecarga de performance das funcionalidades para que nem os serviços, nem as funções normais do smart phone fossem impedidas de funcionar.




Considerando esses desafios, juntamente com os requisitos arquiteturais e de casos de uso, a arquitetura Mobile Host fornece as seguintes características:
  • Suportar requisições HTTP padrão de servidor Web.
  • Fornecimento de Web Service para requisições de clientes usando SOAP sobre HTTP.
  • Capacidade de manipular requisições concorrentes.
  • Suporte à implantação de serviços em tempo de execução.
  • Suporte à análise de desempenho.
Mobile Host foi desenvolvido como um manipulador de Web Service construído sobre o topo de um servidor Web normal. As requisições para o Web Service enviadas por tunelamento HTTP são desviadas e manuseadas por um Web Service manipulador.

A figura abaixo apresenta o núcleo da arquitetura Mobile Host. Na interface HTTP, Mobile Host fica esperando por requisições HTTP GET/POST em soquete do servidor. Quando Mobile Host recebe uma requisição, o soquete do servidor a aceita, cria um soquete para a comunicação e inicia uma nova thread de execução criando uma instância do manipulador de requisições (request handler). Este extrai a mensagem de entrada do canal de entrada do soquete e checa por requisições para o Web Service. Em caso afirmativo, o manipulador de requisições as processa e envia as respostas escrevendo no canal de saída do soquete.



Se a mensagem comprime uma requisição Web Service, o componente manipulador de Web Service (Web Service Handler) processa a mensagem, lendo o corpo da mensagem HTTP e deserializando a requisição SOAP de objetos Java através do processador SOAP. Esses objetos são passados para o manipulador de serviço (service handler), que extrai os detalhes do serviço e invoca o respectivo serviço. Os Web Services implantados no Mobile Host podem acessar o sistema de arquivos local ou qualquer dispositivo externo, como um receptor GPS, usar infravermelho, bluetooth, etc., e podem implementar lógica de negócio. O manipulador de requisições serializa a resposta e prepara uma mensagem de resposta http, que retorna ao cliente como uma resposta HTTP pelo canal de saída do soquete.

Maiores detalhes podem ser obtidos diretamente nas referências abaixo.

[1] S. N. Srirama, M. Jarke, e W. Prinz, ”Mobile Web Service Provisioning,” Proc. Advanced Int. Conf. on Telecommunications and Int. Conf. on Internet and Web Applications and Services, 2006.
[2] S. Srirama, M. Jarke e W. Prinz, “Mobile Host: A feasibility analysis of mobile Web Service provisioning”, Proceedings of the CAISE*06 Workshop on Ubiquitous Mobile Information and Collaboration Systems UMICS '06, 2006.

Arquitetura Mobile SOA

Um exemplo de arquitetura de acesso a Web Services por dispositivos móveis é apresentado por [1]. Em um sentido técnico, a demonstração consiste de uma descrição de serviço (WSDL), uma implementação de serviço e três aplicações clientes, conforme ilustrado pela figura abaixo. JSR 172 é usado para consumo do serviço em dois clientes móveis de funcionalidades idênticas: um para dispositivos com suporte nativos para JSR 172 e outro para dispositivos sem as API’s. Para comparação, uma aplicação cliente de PC baseado em Apache Axis também foi implementado.



A demonstração de conceito da arquitetura proposta identificou que serviços com processamento longo não podem ser usados diretamente, já que JSR 172 somente suporta mensagens síncronas. Operações assíncronas foram simuladas através do uso de uma técnica onde o cliente repetidamente busca por uma resposta, através do envio de requisições de serviço, até que uma resposta é disponibilizada. Assincronicidade é mais propriamente atingida pelo uso da característica de empurrar registro do MIDP, permitindo que aplicações possam ser iniciadas de fora de uma requisição, via SMS (Short Message Service), por exemplo. Em um ambiente onde os dispositivos possuam endereços IP alcançáveis, essa característica de enviar registro do MIDP pode ser combinada com uma pequena versão de um manipulador de Web Services para permitir o fornecimento de serviços por dispositivos leves.

[1] R. Tergujeff, J. Haajanen, J. Leppänen e S. Toivonen, "Mobile SOA: Service Orientation on Lightweight Mobile Devices", IEEE International Conference on Web Services (ICWS 2007), 2007.

sexta-feira, 11 de janeiro de 2008

Composição de serviços ubíqüos

Diversos trabalhos estão sendo desenvolvidos com o intuito de aperfeiçoar as tecnologias relacionadas a computação ubíqua e SOA. [1] propõe a composição de serviços ubíqüos, dividindo a arquitetura do sistema em três categorias de serviço, baseados nas funcionalidades e nos papéis que eles executam, conforme ilustra a figura abaixo.



[1] J. Xia, C. Chang, T. Kim, H. Yang R. Bose e A. Helal, “Fault-resilient Ubiquitous Service Composition”, The 3rd IET International Conference on Intelligent Environments (IE’07), to be held in Ulm, Germany, 24-25 de Setembro, 2007.

Um pouco mais sobre padrões de implementação

A especificação JSR 172 contém algumas limitações notáveis, testadas na prática, a maioria delas devido aos requisitos do WS-I Basic Profile [1].

Soluções baseadas em software para consumo de Web Services móveis também existem. MIRAE [2] é um projeto da Apache Software Foundation que implementa JSR 172. Ele fornece conectividade a Web Services sobre qualquer plataforma MIDP, sem necessitar de suporte nativo para JSR 172. Uma biblioteca SOAP de código aberto chamada kSOAP [3] está disponível há algum tempo para ambientes Java. Adequação a dispositivos sem suporte a JSR 172 e habilidade para acessar serviços não conformes ao WSI, torna kSOAP ainda relevante [4].

Embora as tecnologias atuais permitam, até com certa facilidade, o acesso a Web Services por dispositivos móveis, o fornecimento de Web Services por esses dispositivos é bem mais complicado. Conforme constatado por [5], o estado-da-arte no fornecimento de Web Services através de dispositivos móveis parece estar ainda na sua “infância”. Atualmente, muitas pesquisas estão sendo feitas para verificar a viabilidade de utilização de dispositivos móveis com fornecedores de Web Services, embora muito poucos protótipos de implementações tenham sido criados, incluindo os de Pham e Gehlen [6] e Srirama et al. [5] [7]. A Nokia está fazendo sua parte ao criar seu Nokia Web Services Framework [8]. Implementações públicas ainda não estão disponíveis. Os desafios em executar aplicações complexas em dispositivos móveis geralmente incluem sobre sobrecarga de comunicação, pouca memória, performance e consumo de energia. Além disso, a implementação de fornecedores móveis de Web Services é complicada por obstáculos adicionais, tais como manter um endereço público encontrável para o serviço.

Algumas organizações estão tentando padronizar essa questão de acesso a Web Services por dispositivos móveis. É o caso, por exemplo, da Open Mobile Alliance (OMA) [9], através de sua especificação OMA Web Services 1.0. Esse padrão define orientações de como os Web Services devem expostos, descobertos e consumidos utilizando tecnologias Web Services padrões.

[1] WS-I Basic Profile. Disponível em http://www.wsi.org/Profiles/BasicProfile-1.0.html.
[2] MIRAE. Disponível em http://people.apache.org/~ias/mirae/.
[3] kSOAP 2. Disponível em http://www.ksoap.org/.
[4] R. Tergujeff, J. Haajanen, J. Leppänen e S. Toivonen, "Mobile SOA: Service Orientation on Lightweight Mobile Devices", IEEE International Conference on Web Services (ICWS 2007), 2007.
[5] S. N. Srirama, M. Jarke, e W. Prinz, ”Mobile Web Service Provisioning,” Proc. Advanced Int. Conf. on Telecommunications and Int. Conf. on Internet and Web Applications and Services, 2006.
[6] L. Pham e G. Gehlen, “Realization and Performance Analysis of a SOAP Server for Mobile Devices”, Proc. 11th European Wireless Conf. 2005, vol. 2, Nicosia, Cyprus, VDE Verlag, 2005.
[7] S. Srirama, M. Jarke e W. Prinz, “Mobile Host: A feasibility analysis of mobile Web Service provisioning”, Proceedings of the CAISE*06 Workshop on Ubiquitous Mobile Information and Collaboration Systems UMICS '06, 2006.
[8] Nokia Web Services Framework for Devices. Disponível em http://www.forum.nokia.com/main/resources/technologies/ web_services/index.html.
[9] OMA, Open Mobile Alliance, Disponível em http://www.openmobilealliance.org/.

quarta-feira, 9 de janeiro de 2008

Padrões de implementação

As principais plataformas de desenvolvimento de aplicações também possuem soluções para a utilização de dispositivos moveis em SOA. A Microsoft possui suporte a Web Services em dispositivos móveis há algum tempo, através de seu .NET Compact Framework [1].

Uma visão geral sobre como consumir Web Services a partir de dispositivos móveis com Java é apresentada por [2]. Para essa plataforma, a tecnologia mais importante para clientes móveis é Java 2 Platform, Micro Edition (J2ME), especificamente J2ME Web Services APIs (WSA) [3], também conhecida como JSR 172. Essa tecnologia foi projetada para acomodar uma variedade de dispositivos de mão e embarcados e é composta por uma configuração (configuration) e um perfil (profile). A configuração consiste de uma máquina virtual (Java Virtual Machine – JVM), bibliotecas de núcleo, classes e API’s (Application Programming Interface). Ela define um conjunto mínimo de características JVM e bibliotecas de classes disponíveis em uma categoria particular de dispositivos. O perfil define um conjunto mínimo de API’s para uma família particular de dispositivos. Perfis são implementados sobre uma configuração particular, e aplicações são escritas para um perfil particular, conforme ilustra a Figura 2. JSR 172 baseia-se, portanto, nas especificações CLDC (Connected Limited Device Configuration) e MIDP (Mobile Information Device Profile).

Abaixo seguem algumas ilustrações retiradas de [2]. A propósito, o artigo é uma referência muito interessante sobre o que é possível fazer com SOA em dispositivos móveis, enfatizando a a implementação de Web Services.







[1] .NET Compact Framework. Disponível em http://msdn2.microsoft.com/ptbr/netframework/aa497273.aspx.

[2] A. M. Jankowska e K. Kurbel, “Service-Oriented Architecture Supporting Mobile Access to an ERP System”, Ferstl, O. et al. (Eds.): Wirtschaftsinformatik 2005 - eEconomy, eGovernment, eSociety, Physica-Verlag, Heidelberg, pp. 371-390, 2005.

[3] J2ME Web Services APIs (WSA), JSR 172. Disponível em http://java.sun.com/products/wsa/.

Computação ubíqua e arquiteturas orientadas a serviço

A popularidade de SOA estende-se ao domínio da computação ubíqua. Suas características de baixo acoplamento e independência de plataforma a fazem um candidato ideal para integrar dispositivos ubíqüos. Enquanto a semântica de SOA está sendo padronizada, seu uso em computação ubíqua está sob pesquisa e sendo experimentada. A importância dessa relação deve-se ao fato dos dispositivos móveis estarem tornando-se a nova plataforma cliente das aplicações. Embora, no restante deste artigo seja usualmente citado o termo dispositivo móvel, o seu real significado é qualquer dispositivo, normalmente de pequeno porte, móvel ou não, como por exemplo um aparelho de ar condicionado, um refrigerador, um forno de microondas, etc.

A relação de SOA com a computação ubíqua está diretamente ligada à utilização de Web Services em dispositivos móveis. Essa utilização pode ser feita de duas formas: dispositivos móveis como consumidores de Web Services, a mais comum; dispositivos móveis como fornecedores de Web Services, até certo ponto, ainda um desafio.

Portanto [1], dispositivos móveis podem tanto consumir como fornecer serviços. Essencialmente, um dispositivo móvel torna-se um par (peer). Ambas as características são necessárias para uma extensão sem costura de SOA para pequenos dispositivos, o que habilitaria a participação transparente em processo de negócio.

[1] D. Linthicum, “SOA Meets Mobile Devices”, A CEO's Guide to EAI, SOA, & Business Integration, Outubro de 2004. Disponível em http://blogs.ittoolbox.com/eai/cto/archives/soameets-mobile-devices-2005.

terça-feira, 8 de janeiro de 2008

Próximas pesquisas

As próximas pesquisas que serão feitas, até o final de janeiro de 2008, dizem respeito à questão da infra-estrutura de software necessária para a utilização de SOA em dispositivos móveis. Deverão ser pesquisados assuntos como Web Services, composição de Web Services, orquestração, busca de Web Services, etc. Basicamente, deverá ser encontrado o que se tem de fato (estado da arte) sobre o assunto "SOA para dispositivos móveis": ferramentas, software, hardware, pesquisas, etc.

Logo depois disso, será a vez de aprofundarmos o conhecimento sobre arquitetura e meta-arquitetura de software.

E vamos lá!

Objetivos do blog

Olá a todos

O objetivo deste blog é ser o local onde os assuntos que estão sendo pesquisados pelo grupo de pesquisa de Engenharia de Software e Linguagens de Programação serão publicados para que o grupo todo possa nivelar certo conhecimento.

Até breve!