Estudo Comparativo de Middlewares para

Computacao Ubıqua

Sand Luz Correa

Novembro 2006

Sumario

1 Introducao 1

1.1 Requisitos para computacao ubıqua . . . . . . . . . . . . . . . 21.2 Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . 5

2 Estudo de Caso 7

2.1 Gaia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Gaia Kernel . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1.1 Gerenciamento de componentes . . . . . . . . 82.1.1.2 Gerenciamento de eventos . . . . . . . . . . . 82.1.1.3 Gerenciamento de contexto . . . . . . . . . . 92.1.1.4 Servico de presenca . . . . . . . . . . . . . . . 92.1.1.5 Servico de repositorio . . . . . . . . . . . . . 102.1.1.6 Sistema de arquivo de contexto . . . . . . . . 10

2.1.2 Gaia Application Framework . . . . . . . . . . . . . . . 112.1.3 Inicializacao do middleware . . . . . . . . . . . . . . . 11

2.2 one.world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Servicos fundamentais . . . . . . . . . . . . . . . . . . 122.2.2 Servicos do sistema . . . . . . . . . . . . . . . . . . . . 13

2.2.2.1 Servico de gerenciamento de dados . . . . . . 132.2.2.2 Servico de comunicacao . . . . . . . . . . . . 142.2.2.3 Servico de descoberta . . . . . . . . . . . . . 152.2.2.4 Servico de checkpoint e migracao . . . . . . . 16

2.3 iRoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Heap de eventos . . . . . . . . . . . . . . . . . . . . . . 172.3.2 Heap de dados . . . . . . . . . . . . . . . . . . . . . . 182.3.3 iCrafter . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Oxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.1 MetaGlue . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.2 GOALS . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 EasyLiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

i

3 Comparacao e Conclusoes 24

3.1 Estudo comparativo . . . . . . . . . . . . . . . . . . . . . . . . 243.1.1 Aspectos Gerais . . . . . . . . . . . . . . . . . . . . . . 243.1.2 Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ii

Lista de Figuras

1.1 Template de comparacao utilizado. . . . . . . . . . . . . . . . 6

2.1 Arquitetura Gaia. . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Arquitetura one.world . . . . . . . . . . . . . . . . . . . . . . 122.3 Arquitetura iRoom. . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Heap de eventos. . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Visao de um espaco interativo em Oxygen . . . . . . . . . . . 202.6 Arquitetura EasyLiving . . . . . . . . . . . . . . . . . . . . . . 22

iii

Lista de Tabelas

3.1 Comparacao segundo aspectos gerais . . . . . . . . . . . . . . 273.2 Comparacao segundo aspectos tecnologicos . . . . . . . . . . . 283.3 Comparacao segundo aspectos de servicos . . . . . . . . . . . 28

iv

Resumo

Computacao ubıqua apresenta-se como uma abordagem visionaria e promis-sora para o futuro da computacao, uma vez que o poder de processamentotorna-se cada vez mais acessıvel e onipresente na vida das pessoas. Adicio-nalmente, dispositivos moveis e estacionarios sao incorporados aos ambientesfısicos para estender a percepcao dos usuarios, bem como suas atividades co-tidianas. Entretanto, para que esta visao se concretize e se torne realidade,aplicacoes devem se adaptar constantemente a dinamicidade do ambientede execucao. Isto exige infra-estruturas de software (middlewares) que tor-nem possıvel e facilitem o desenvolvimento e execucao de tais aplicacoes.Neste trabalho, discutimos cinco infra-estruturas de software para apoiar aconstrucao de aplicacoes que fazem uso de cenarios de computacao ubıqua.Em particular, a arquitetura e os servicos providos em cada middleware saoapresentados e comparados entre si em relacao a alguns criterios.

Capıtulo 1

Introducao

Segundo Weiser [1], a era da informatica para o seculo XXI vive uma evolucaopara um mundo onde os dispositivos digitais serao parte integral e invisıveldo ambiente natural das pessoas. Nesse mundo, a constante presenca dosdispositivos digitais no meio em que se vive seria tao natural que a presencados mesmos se tornaria imperceptıvel. Weiser denominou tal cenario decomputacao ubıqua.

Porem, a transparencia idealizada pela computacao ubıqua requer umarelacao entre usuario e computador diferente daquela tradicionalmente conce-bida, na qual o computador e um dispositivo de processamento e as interacoescom o mesmo ocorrem atraves de dispositivos tradicionais de entrada e saıda.Ao contrario, neste novo cenario, a computacao nao reside em apenas umdispositivo, mas em diversos recursos de diferentes tamanhos e capacidades,espalhados por todo lugar e a qualquer momento.

Como consequencia direta desta nova forma de interacao, o espaco fısicoincorpora um conjunto de dispositivos computacionais e de comunicacao queestendem as atividades humanas com informacoes digitais. Nesse sentido,tres requisitos se tornam essenciais para um cenario de computacao ubıqua:i) a mobilidade dos dispositivos, uma vez que os usuarios se movem atravesdo mundo fısico; ii) a capacidade de interacao dos dispositivos moveis comoutros dispositivos, recursos e servicos que permeiam um ambiente; e iii)aplicacoes sensıveis ao contexto do ambiente em que executam, uma vez quea grande dinamicidade do ambiente de execucao exige que as aplicacoes seadaptem as novas condicoes com o mınimo de intervencao humana.

Entretanto, tais ambientes altamente interativos e orientados a usuariosexigem novas infra-estruturas de software para operar seus recursos, mo-nitorar propriedades de contexto e auxiliar no desenvolvimento e execucaode aplicacoes. Abordagens tradicionais para construcao de aplicacoes dis-tribuıdas se tornam, entao, inapropriadas para computacao ubıqua, uma vez

1

que elas: i) escondem da aplicacao a distribuicao, dificultando o conheci-mento do contexto; ii) apoiam-se em modelos de programacao que esten-dem modelos de processamento centralizados como, por exemplo, chama-das de procedimento remoto; e iii) assumem a existencia de um ambientede execucao mais estatico, onde os recursos apresentam alta disponbilidade.Ao tornar a distribuicao transparente, o acesso a um recurso remoto e tra-tado da mesma forma que o acesso a um recurso local, dificultando possıveisadaptacoes para refletir, de forma mais adequada, a qualidade do servicocorrente. Adicionalmente, num ambiente em que pessoas e dispositivos semovem constantemente, e frequente a indisponibilidade de alguns recursose, portanto, isto nao pode ser tratado como uma excecao ou caso extremo.Portanto, a inadequacao dos sistemas distribuıdos tradicionais para suportea computacao ubıqua da origem ao questionamento de como estruturar e darsuporte a aplicacoes pervasivas. Alguns projetos foram propostos com estesobjetivo e sao apresentados neste trabalho.

Assim, este trabalho tem como objetivo apresentar algumas proprostas deinfra-estrutura e middleware para computacao ubıqua. Mais especificamente,sao apresentados cinco projetos: Gaia, one.world, iRoom, Oxygen e EsyLi-ving. A arquitetura proposta em cada middleware e os servicos implemen-tados sao discutidos no proximo capıtulo deste trabalho. Em seguida, e rea-lizada uma comparacao entre as cinco abordagens considerando-se criteriosfundamentais para a implementacao de computacao ubıqua e a maturidadede cada solucao.

Este trabalho esta organizado da seguinte forma: ainda no capıtulo 1discutimos na Secao 1.1 os requisitos fundamentais para computacao ubıqua eque sao usados como criterios para comparacao dos cinco projetos estudados;a metodologia escolhida para elaboracao deste trabalho, bem como o criteriode selecao dos projetos estudados sao relatados na Secao 1.2. No capıtuloseguinte, a arquitetura de cada middleware e apresentada, detalhando seusservicos principais. O utlimo capıtulo deste trabalho traz uma comparacaoentre os projetos apresentados e algumas conclusoes sobre o estado da artede infra-estruturas de software para computacao ubıqua.

1.1 Requisitos para computacao ubıqua

A inadequacao das abordagens tradicionais para construcao de sistemas dis-tribuıdos faz emergir a questao de como estruturar infra-estrururas de suportepara a construcao de aplicacoes ubıquas. Para ajudar a definir novas alter-nativas, [2] identifica alguns requisitos essenciais e categorias de subsistemasque devem fazer parte de qualquer infra-estrutura de software para suporte

2

a computacao ubıqua. Tais requisitos e subsistemas sao discutidos a seguir.

Descoberta de recursos

A comunicacao entre aplicacoes que executam sobre um middleware paracomputacao ubıqua inicia-se com a descoberta dos recursos disponıveis emum ambiente ou espaco fısico. O termo ”descoberta”e usado para se re-ferir a um processo mais espontaneo e ativo de procura por recursos, noqual os proprios recursos sao capazes de se descobrirem e se apresentarema rede e aos outros recursos. Este processo, por sua vez, contrasta com aforma passiva com que os servicos de lookup, tradicionalmente usados emsistemas distribuıdos, funcionam, onde requisitantes de recursos submetemsuas requisicoes a diretorios de servicos responsaveis por atende-la. Existematualmente varios protocolos de descoberta de servico implementados como,por exemplo, SSDP [3], UDDI [4], WSDL [5] e o servico de descoberta deJini. Em geral, os protocolos de descoberta de servico diferenciam-se emrelacao a eficiencia e capacidade do servico. Assim, alguns protocolos saobastante complexos e proporcionam servico de descoberta altamente auto-matizado. Outros, entretanto, sao mais simples e requerem algum tipo deintervencao manual ou interacao estatica. Servicos de descoberta geralmentesao classificados em relacao ao criterio usado para descobrir servicos e a di-namicidade do processo. Em relacao ao primeiro criterio, servicos podemser identificados por nome ou por atributos. Em relacao ao segundo criterio,servicos podem ser identificados estaticamente, atraves de early bind, ou di-namicamente, late bind, onde um servico e identificado durante o processode roteamento da mensagem.

Subscricao e servico

O requisito subscricao e servico corresponde ao subsistema que implementa apassagem de mensagem para registro e acesso a um servico, bem como noti-ficacao de eventos entre as aplicacoes. De forma geral, aplicacoes ubıquas saocompostas por varios componentes, cada um implementando uma unica fun-cionalidade. Para obter o comportamento completo e esperado da aplicacao,tais componentes necessitam de comunicacao intra-aplicacao para se sincro-nizarem. Neste sentido, o subsistema de subscricao e servico e fundamental,uma vez que ele permite que as entidades de aplicacoes distribuıdas man-tenham as informacoes de estado entre as mesmas, provendo a abstracaonecessaria para uma entidade difundir informacoes de seu estado, bem comoatualiza-lo quando o estado de outras entidades mudam. Para efeito de ava-liacao, subsistemas de subscricao e servico se diferenciam entre si em relacao

3

a API de programacao oferecida. Assim, alguns subsistemas oferecem umgrande conjunto de operacoes, enquanto que outros proveem uma API maissimples. Outros criterios de avaliacao do subsistema de subscricao e servicoincluem a escalabilidade do subsistema, ou seja, o numero aplicacoes utili-zando o subsistema e o tempo gasto para propagar atualizacoes de estado.

Armazenamento de dados

Muitas aplicacoes ubıquas, especialmente aquelas que acessam dados mul-timıdia, necessitam transferir quantidades significativas de dados estrutura-dos. Logo, o subsistema de armazenamento de dados e streams e responsavelpor tratar essa movimentacao de dados estruturados entre os diferentes nosdo ambiente. Em muitos casos, o sistema de armazenamento e usado tambempara salvar o estado dos componentes do sistema. Esta opcao e importanteporque facilita o acesso ao estado do componente, facilitando assim servicosde reconfiguracao, migracao e, em alguns casos, tolerancia a falhas.

Compartilhamento de poder de processamento

Um subsistema de compartilhamento de poder de processamento, em umambiente ubıquo, permite que aplicacoes que estejam executando facam usode recursos de computacao remotos, sempre que os mesmos se tornaremnecessarios. Adicionalmente, tal subsistema e responsavel tambem pelo rear-ranjo dos recursos disponıveis entre os clientes correntes, de forma a garantirmelhor qualidade de servico a todos que fazem uso do ambiente. Para isto,o subsistema deve prover mecanismos que possam descubrir tempo de CPUdisponıvel para processamento, mecanismos de escalonamentos dinamicosnos nos com maior capacidade de processamento e funcoes de migracao deentidades para os dispositivos existentes.

Gerenciamento de contexto

Um subsistema de gerenciamento de contexto tem por objetivo definir umalinguagem comum para descrever o contexto de um ambiente de execucaoe uma linguagem para inspecionar ou consultar o estado de um contextodescrito. Este subsistema e construıdo, entao, no top do sistema de subs-cricao e servico e do subsistema de armazenamento de dados. Isto se deveporque, em geral, o gerenciamento de contexto consiste na monitoracao dosvalores assumidos pelos dados que descrevem o contexto e na notificacao,as aplicacoes interessadas, de qualquer mudanca percebida. O subsistem degerenciamento de contexto e, portanto, um dos servicos mais importantes de

4

um middleware para computacao ubıqua, ja que muitas das tarefas executa-das neste cenario necessitam de uma visao consistente de um ambiente, pornatureza, dinamico.

1.2 Metodologia utilizada

A metodologia utilizada para elaboracao deste trabalho consistiu em pesquisabibliografica sobre o tema, sendo esta dividida em tres partes: levantamentodo estado da arte de middlewares para computacao ubıqua; selecao de umconjunto de casos para estudo da arquitetura e dos servicos implementados;e definicao de um conjunto de servicos essenciais, de tal forma que os casosaqui estudados pudessem ser comparados entre si. Definimos como criteriode selecao de um projeto seu tamanho e sua maturidade. Assim os exemplosaqui estudados foram escolhidos por serem projetos de medio ou grande portee por apresentarem um grau de maturidade satisfatorio.

Em relacao aos criterios de comparacao, optamos por adotar a metodolo-gia descrita em [2], a qual sugere a avaliacao de middlewares para computacaoubıqua em relacao aos servicos essenciais que os mesmos devem implemen-tar. Entretanto, neste trabalho, esta metodologia foi estendida para abrangertambem requisitos como paradigma de programacao, gerenciamento e com-posicao de servicos e tolerancia a falhas.

A figura 1.1 ilustra o template de comparacao a ser usado neste traba-lho. Os criterios de comparacao foram divididos em tres categoria: aspectosgerais, tecnologia e servicos implementados. A categoria aspectos gerais in-clue os requisitos: grupo empreendedor, data de inıcio do projeto e objetivosdo projeto. A categoria tecnologia inclue os requisitos que descrevem umprojeto em relacao a sua tecnologia. Incluem-se nesta categoria: paradigmade programacao, plataformas e linguagem de programacao suportados e mo-delo de comunicacao adotado. A categoria servicos inclue os requisitos quedescrem um projeto em termos dos servicos implementados, como por exem-plo, instanciacao e servico de configuracao, descoberta de servicos, servico decontexto, escalabilidade e tolerancia a falhas.

5

Figura 1.1: Template de comparacao utilizado.

6

Capıtulo 2

Estudo de Caso

Este capıtulo discute a arquitetura e os servicos implementados em cincomiddlewares para computacao ubıqua. A Secao 2.1 apresenta o Gaia, ummiddleware desenvolvido na universidade de Urbana-Champaign que provesuporte para aplicacoes ubıquas inseridas em espacos ativos; a Secao 2.2discute um projeto da universidade de Washington, denominado one.world,cujo foco e prover um conjunto de servicos integrados para construcao deaplicacoes pervasivas; a Secao 2.3 apresenta o iRoom, um projeto desenvol-vido na universidade de Stanford e voltado para a coordenacao de espacosinterativos; a Secao 2.4 apresenta o Oxygen, um projeto da universidade doMIT e, finalmente, a Secao 2.5 introduz o EasyLiving, um infra-estrutura dedesenvolvimento de aplicacoes ubıquas da Microsoft.

2.1 Gaia

Gaia [6] [7] e um middleware distribuıdo que coordena entidades de soft-ware e dispositivos heterogeneos presentes em um espaco fısico. Trata-sede um meta-sistema operacional, desenvolvido na universidade de Urbana-Champaign, cujo desenvolvimento foi resultado de seis anos de pesquisa emmiddleware reflexivo e middleware para computacao movel e ubıqua. Gaiagerencia os recursos e servicos de um espaco ativo, abstraindo a comple-xidade e heterogeneidade associada a um ambiente de computacao ubıqua.Um espaco ativo consiste em um espaco fısico coordenado por uma infra-estrutura de software baseada em contexto que aumenta a habilidade deusuarios moveis interagirem e configurarem seu espaco fısico e digital. Gaiaprove servicos de localizacao, contexto, eventos e repositorios de informacoessobre os espacos ativos gerenciados. O sistema e construıdo como um con-junto de objetos distribuıdos. Os principais blocos de construcao de Gaia

7

sao ilustrados na figura 2.1: Gaia Kernel, Gaia Application Framework eApplications. As subsecoes seguintes descrevem cada bloco de construcao.

Figura 2.1: Arquitetura Gaia.

2.1.1 Gaia Kernel

Aplicacoes Gaia sao distribuıdas, moveis e baseadas em componentes, e,portanto, requerem suporte a instanciacao, execucao e gerenciamento decomponentes remotos. O sistema de gerenciamento e deployment dos ob-jetos distribuıdos que constituem os servicos do middleware e denominadoGaia Kernel e constitui-se de seis servicos basicos: servico de gerenciamentode componentes, servico de gerenciamento de evento, servico de presenca,servico de contexto, servico de repositorio e um sistema de arquivo de con-texto.

2.1.1.1 Gerenciamento de componentes

O servico de gerenciamento de componentes e responsavel por criar, destruire carregar todos os componentes e aplicacoes Gaia. Componentes Gaia saoobjetos distribuıdos e requerem um middleware de comunicacao para dar su-porte a comunicacao remota. A implementacao atual de Gaia utiliza CORBA[8] para este proposito. Nos de execucao remotos se registram a um espacoativo e hospedam a execucao de componentes Gaia.

2.1.1.2 Gerenciamento de eventos

O servico de gerenciamento de eventos e responsavel pela distribuicao deeventos em um espaco ativo e implementa um modelo de comunicacao fraca-mente acoplado baseado em fornecedores, consumidores e canais de eventos.

8

Cada canal tem um ou mais fornecedor, os quais proveem informacoes aum ou mais consumidores que as recebem. Gaia define um conjunto padraode canais de eventos para notificar componentes Gaia interessados em no-vos servicos, aplicacoes, pessoas, erros e continuidade de servicos providospor componentes Gaia (heartbeats component). Adicionalmente, aplicacoestambem podem definir seus proprios canais de eventos para notificar mu-dancas em seus estados, bem como se inscreverem em canais de eventos parareceberem notificacoes de mudancas no ambiente. Este servico de subscricaoe baseado no servico de eventos fornecido por CORBA.

2.1.1.3 Gerenciamento de contexto

Aplicacoes Gaia usam informacoes de contexto para adaptar seus comporta-mentos e acomodarem-se a novas atividades do usuario. O servico de contextopermite que as aplicacoes se registrem e consultem informacoes particularesde contexto. A infra-estrutura de contexto de Gaia foi inspirada em [9] econsiste em um conjunto de componentes, denominados provedores de con-texto, que fornecem informacoes sobre o contexto atual. Alguns exemplosde provedores de contexto incluem sensores que detectam a localizacao depessoas, sensores que monitoram as condicoes (temperatura, audio) de umespaco e componentes que inferem contextos de mais alto nıvel baseados eminformacoes sensoriadas. Existe um registrador que mantem uma lista dosprovedores de contexto disponıveis para que as aplicacoes possam encontrar ofornecedor que gerencia o contexto no qual elas estao interessadas. O modelode contexto de Gaia e baseado em logica de primeira ordem e algebra boleana.Um contexto e representado atraves de uma tupla composta por quatro predi-cados: Context(< ContextType >, < Subject >, < Relater >, < Object >).ContextType refere-se ao tipo de contexto que esta sendo descrito; Subject

refere-se a pessoa, lugar ou coisa a que o contexto se refere; Object e o valorassociado ao Subject; Relater relaciona o Subject e o Object de um predi-cado como, por exemplo, um operador de comparacao. Como exemplo, atupla Context(< localizacao >, < sand >, < entrando >, < sala520 >) des-creve um contexto do tipo localizacao, indicando que o usuario sand entrouna sala 520.

2.1.1.4 Servico de presenca

Como uma infra-estrutura ciente dos recursos de um espaco fısico, Gaiamantem informacoes sobre a presenca dos mesmos em um espaco ativo.Assim, o servico de presenca e responsavel por detectar entidades digitais(servicos e aplicacoes) e fısicas (pessoas, moveis, dispositivos, etc) presen-

9

tes em um espaco ativo. Para isto, Gaia define quatro tipos de entidades(Aplicacoes, Servicos, Dispositivos e Pessoas) que sao detectadas por doissubsistema: servico de presenca digital e servico de presenca fısica. O pri-meiro subsistema detecta a presenca de entidades digitais, as quais enviamsinais de heartbeats periodicamente para notificarem suas presencas. Quandouma entidade digital interrompe o envio deste sinal, o subsistema de presencadigital assume que a entidade nao esta mais disponıvel no ambiente e notificasua ausencia para o resto do espaco. O subssitema de presenca fısica e res-ponsavel por detectar a presenca de entidades fısicas presentes em um espacoativo. Em geral, isto e feito atraves de diferentes sensores que proativamentedetectam a presenca e, se possıvel, a localizacao da entidade.

2.1.1.5 Servico de repositorio

O servico de repositorio armazena informacoes (tais como propriedades) so-bre todas as entidades de software e hardware contidas em um espaco ativo,alem de prover funcionalidades para recuperar entidades baseadas em atri-butos especıficos. Tal servico e essencial para que as entidades de um espacoativo aprendam sobre as propriedades dos recursos ali disponıveis. Todo re-curso de um espaco ativo possui um arquivo XML associado que descrevesuas propriedades. Quando novos recursos sao introduzidos, o servico derepositorio os contacta para obter o descritor XML, que e entao armaze-nado. Atualmente, o servico de repositorio de Gaia usa o servico de traderde CORBA. Para ter ciencia da entrada ou saıda de entidades de um espacoativo, o servico de repositorio se subscreve a um canal de evento definidopelo servico de presenca.

2.1.1.6 Sistema de arquivo de contexto

Espacos ativos normalmente sao designados a tarefas especıficas. Comoconsequencia, em muitos casos, o contexto da tarefa pode determinar a in-formacao que e sigfinicativa, evitando informacoes irrelevantes. Para tratartal propriedade de espacos ativos, o sistema de arquivo de contexto (CFS)e especificado. Assim, um CFS consiste em um servico de arquivo onde osmesmos sao organizados de acordo com um contexto. Seu objetivo e diminuirmuitas tarefas que sao tradicionalmente executadas manualmente atraves deinformacoes de contexto. Mais especificamente, o contexto e usado para: au-tomaticamente disponibilizar dados pessoais para uma aplicacao baseando-se na presenca de usuarios; organizar dados para simplificar localizacao dosdados mais importantes para uma aplicacao; e recuperar dados no formatoexigido pelas preferencias de um usuario ou caracterısticas de um dispositivo.

10

2.1.2 Gaia Application Framework

Application Framework prove mecanismos para construir, executar e adaptaraplicacoes ja existentes para espacos ativos. O framework e composto poruma infra-estrutura distribuıda e baseada em componentes, um mecanismode mapeamento e um grupo de polıticas que podem ser aplicadas para cus-tomizar diferentes aspectos das aplicacoes. A infra-estrutura do frameworke baseada no particionamento proposto pelo modelo Model-View-Controller[10] e e formado por quatro componentes: modelo, apresentacao, controle ecoordenacao. Os tres primeiros constituem o bloco de construcao de qual-quer aplicacao, enquanto que o componente de coordenacao prove funciona-lidades de meta-nıvel as aplicacoes. O mecanismo de mapeamento e usadopara customizar aplicacoes para diferentes cenarios. As polıticas customi-zam diferentes aspectos de uma aplicacao, como, por exemplo, confiabilidade,reacoes a mudancas no ambiente e implementacao de mobilidade. Applica-tion Framework se apoia em polıticas para tratar tais questoes. Dessa forma,usuarios podem definir suas proprias polıticas ou usar as polıticas default doframework.

2.1.3 Inicializacao do middleware

Gaia implementa um protocolo de inicializacao que interpreta um arquivode configuracao e inicializa o kernel do middleware. O arquivo de confi-guracao contem informacoes sobre os servicos do kernel, como o nome doservico, o nome da interface, os nos que hospedarao o servico, a polıtica deinstanciacao do servico, etc. A instanciacao dos servicos segue a seguinteordem: repositorio de interfa (CORBA), nos de execucao remotos, servico denomes (CORBA), gerenciamento de evento, servico de presenca, servico decontexto, sistema de arquivo de contexto, servico de repositorio.

2.2 one.world

one.world [11] [12] e framework generico para computacao ubıqua desenvol-vido na universidade de Washington. Sua arquitetura foi concebida enfati-zando decisoes de projetos apropriadas para um ambiente altamente dinamico,focando-se em requisitos de tolerancia a falhas, checkpoint e mobilidade deaplicacoes. Tres princıpios foram considerados para o projeto da arquiteturado middleware: prover um conjunto de servicos fundamentais, expressa-loscomo blocos de construcao e particionar a arquitetura do middleware en-tre espaco do sistema e espaco do usuario. Os servicos fundamentais em

11

one.world se referem a ciencia de contexto, composicao de servico e compar-tilhamento de informacoes em ambientes ubıquos. Estes servicos executamno espaco do sistema ou kernel, enquanto que o espaco do usuario e destinadopara a execucao de bibliotecas, ferramentas do sistema e aplicacoes. A figura2.2 ilustra a arquitetura do one.world.

Figura 2.2: Arquitetura one.world

2.2.1 Servicos fundamentais

Na figura 2.2, observamos que a arquitetura do one.world e divida entreespaco do usuario e kernel do sistema. Este ultimo, por sua vez, divide-seem servicos fundamentais e servicos do sistema. Quatro componentes imple-mentam os servicos fundamentais: maquina virtual, eventos assıncronos, am-

12

bientes e tuplas. A maquina virtual fornece um ambiente de execucao comuma todos os dispositivos e plataformas presentes no ambiente e foi concebidacomo uma extensao da maquina virtual de Java. Tuplas definem um modelode dados comum a todas aplicacoes, facilitando o compartilhamento de da-dos. Adicionalmente, sao auto-descritivas, de forma que uma aplicacao podeinspeciona-las dinamicamente. Eventos assıncronos constituem-se na unicaforma de comunicacao em toda a arquitetura. Logo, toda comunicacao, localou remota, e feita atraves de sinalizacoes de eventos. Finalmente, ambien-tes correspondem ao mecanismo central para estruturar e compor aplicacoes.Eles desempenhma o papel de containers, encapsulando tuplas, componen-tes de servicos e outros ambientes, criando assim uma estrutura hierarquica.Como processos de um sistema operacional, ambientes proveem protecao, iso-lando as aplicacoes umas da outras e do proprio sistema. Ambientes podemser identificados atraves de um identificador unico ou atraves de um caminho(path name) atribuıdo pelo usuario. Ambientes tambem sao um mecanismoimportante para composicao dinamica: um ambiente controlando varios am-bientes aninhados pode se compor com o proprio kernel e com o mundoexterno.

2.2.2 Servicos do sistema

Alem dos servicos fundamentais, one.world prove um conjunto de servicosde sistemas que servem como blocos de construcao para aplicacoes. Comoilustrado na figura 2.2, os servicos de sistema incluem: servico de migracao,servico de descoberta, servico de armazenamento de tuplas, checkpoint, servicode eventos e maquina de busca.

2.2.2.1 Servico de gerenciamento de dados

O servico de armazenameto de tuplas juntamente com a maquina de buscaformam o servico de gerenciamento de dados, ou seja, a habilidade de con-sultar, armazenar e trocar informacoes na forma de tuplas. Como obser-vado anteriormente, tuplas definem o modelo de dados da arquitetura. Elasconstituem-se em registros auto-descritivos compostos por um nome e umconjunto de atributos. Cada atributo possui um tipo de dados pre-definido.Portanto, tuplas sao declaradas estaticamente e sao fortemente tipadas. Con-tudo, one.world inclui um tipo de tupla especial denominada DynamicTuple.Ao contrario de outras tuplas, os campos de uma tupla dinamica podem seradicionados ou removidos dinamicamente e podem ter qualquer tipo de da-dos. Cada tupla tem um campo identificador e um campo para metadadosinspecionado pelas aplicacoes. Adicionalmente, cada tupla possui um con-

13

junto de metodos que podem ser invocados para refletir sua estrutura e paraacessar a seus dados, permitindo assim que aplicacoes inspecionem e acessemseu conteudo.

Tuplas podem ser recuperadas atraves da maquina de busca, a qual proverecursos para pesquisar tuplas atraves da instanciacao de filtros. Consultasenvolvem comparacoes entre valores e campos da tupla, filtros sobre tipos detuplas e operacoes de conjuncao, disjuncao e negacao. Ao fornecer um mo-delo canonico para manipulacao e troca de dados, o servico de gerenciamentode dados simplifica o compartilhamento de informacoes dentro da arquite-tura. Entretanto, diferentemente de um banco de dados relacional, tuplas saoarmazenadas em ambientes, ou seja, cada ambiente armazena suas propriastuplas. Dessa forma, para acessar uma determinada tupla, uma aplicacaodeve especificar o ambiente que a tupla esta armazenada, associando-se aeste. Seguindo a abordagem Unix, a mesma API de manipulacao de da-dos e usada para acessar dados pela rede. Para acessar um dado pela rede,aplicacoes se associam a um ponto atraves de sockets UDP ou TCP. En-tretanto, e importante observar que a estrutura de entrada e saıda usada noone.world distingue entre armazenamento e rede, ao contrario de oferecer umservico de espaco de tuplas unificado. Assim, o armazenamento de tuplas,nesta arquitetura, nao tem funcao de comunicacao, apenas de persistenciade dados.

2.2.2.2 Servico de comunicacao

O servico de eventos direciona eventos para servicos locais e remotos, sendoo unico modelo de comunicacao da arquitetura. Assim, todas as funciona-lidades da arquitetura sao implementadas como tratadores de eventos e asaplicacoes devem especificar quais eventos desejam receber e quais tratado-res de eventos irao processa-los. Eventos representam dados provenientesde sensores, entradas de usuario ou mudancas no ambiente ou no estado deoutros componentes. Como eventos sao dados, eles tambem sao representa-dos por tuplas. Mas ao contrario das tuplas de dados tradicionais, tuplasde eventos possuem um campo para refereciar o tratador de evento da ori-gem. Este tratador de evento recebe notificacoes de falhas que ocorreramdurante o processamento do evento, bem como o retorno de uma interacaorequisicao-resposta. Assim, tratadores de eventos sao usados tanto para pro-cessar eventos de requisicao como para processar eventos de resposta. Adi-cionalmente, tratadores de eventos implementam uma interface unica comum unico metodo, o qual recebe o evento a ser processado como parametroe nao retornam nenhum resultado. Qualquer resultado de uma interacao re-quisicao-resposta deve ser enviado como um evento normal para o tratador

14

de evento referenciado pelo campo origem da requisicao.Para facilitar reutilizacao, aplicacoes one.world sao constituıdas por com-

ponentes instanciados em um ambiente. Tais componentes importam e ex-portam tratadores de eventos, expondo-os a associacoes. Assim, apos associarum tratador de evento importado a um tratador de evento exportado, even-tos enviados para o tratador importado podem ser processados pelo tratadorexportado. O componente principal da aplicacao tem um metodo de inicia-lizacao estatico que inicializa seus componentes e executa a associacao inicial.Ele e invocado pelo middleware durante o carregamento da aplicacao dentrodo ambiente. Enquanto a aplicacao esta executando, ela pode instanciar com-ponentes adicionais, adicionar ou remover tratadores de eventos importadosou exportados e conectar e desconectar componentes sempre que necessario.E importante notar que, como os tratadores de eventos implementam umainterface unica, o processo de composicao se torna mais simples.

A interacao entre uma aplicacao e seu ambiente e feita de forma similar.Para uma aplicacao, seu ambiente e um componente como outro qualquer.Cada ambiente importa um tratador de evento denominado main que deveser associado ao componente principal da aplicacao, antes que esta possa serinicializada. Este tratador de evento e usado pelo middleware para informara aplicacao de eventos como falhas no ambiente, restauracao ou migracao.Tambem de forma similar, um ambiente pode se comunicar com o middlewareatraves da exportacao de um tratador de eventos denominado monitor. As-sim, um ambiente raiz se conecta ao middleware para executar operacoes deentrada e saıda, servico de descoberta e ser notificado sobre mudancas.

2.2.2.3 Servico de descoberta

O servico de descoberta implementado em one.world e construıdo sobre a in-terface de tratamento de eventos. A API de descoberta de servico oferece tresoperacoes: export, resolve e send. A operacao export exporta um tratadorde evento, tornando-o acessıvel atraves da rede. Isto e feito estabelecendo-se um mapeamento entre um descritor e o tratador de evento. Todos osmapeamentos sao entao armazenados em um diretorio na rede. A operacaoresolve procura por um ou mais tratadores de eventos neste diretorio. Elarecebe como parametro uma consulta e retorna um ou mais tratadores deeventos que satisfazem a consulta. export/resolve implementam um servicode descoberta estatico. Um processo de discoberta mais dinamico e imple-mentado pela operacao send uma vez que ela combina execucao de consultae roteamento de evento em uma unica operacao.

15

2.2.2.4 Servico de checkpoint e migracao

O servico de checkpoint captura o estado da execucao de uma arvore de ambi-entes e o salva como uma tupla, possibilitando reverter o estado de execucaoda arvore de ambientes posteriormente. Portanto o servico de checkpointimplementa um mecanismo de recuperacao de estado que pode ser usadotanto para recuperacao de falhas como tambem para servico de migracao.Este ultimo, prove a habilidade de mover ou copiar um ambiente, incluindoseu conteudo (tuplas e componentes da aplicacao), localmente ou para outrodispositivo. O servico de migracao e essencial para aplicacoes que seguemusuarios que se deslocam pelo espaco fısico.

2.3 iRoom

Interative Room [13], [14], ou iRoom, e um prototipo desenvolvido na uni-versidade de Stanford como resultado de um projeto em espacos interativospara grupos de trabalho. Iniciado em 1999, a ideia fundamental do projetoe experimentar cenarios de computacao ubıqua com o foco na investigacaode como mapear um unico espaco fısico para uma infra-estrutura subjacentede software e hardware, enfatizando um modelo de interacao correspondente.Tal infra-estrutura de software subjacente foi denominada Interative RoomOperating System [15], ou iROS, e consiste em um meta-sistema operacionalque integra diversos dispositivos de computacao, cada qual com seu propriosistema operacional. Cada espaco interativo deve executar uma instancia doiROS para que o mesmo possa ser coordenado. Assim, para interagir com umespaco, uma aplicacao ou dispositivo deve contactar-se a instancia do iROSdo local.

Por gerenciar um unico espaco fısco e por estar interessado especialmentena investigacao de modelos de interacao, a arquitetura do iROS foi concebidasegundo tres criterios: economia de mecanismos, simplicidade de aplicacoesclientes e um modelo de comunicacao centralizado e baseado em broadcast. Afigura 2.3 mostra os tres subsistemas que compoem o iROS: iCrafter, servicosde sistema e gerenciamento de eventos. Tais subsistemas foram projetadospara lidar com tres necessidades basicas de um espaco interativo: movi-mentacao de controle, movimentacao de dados e coordenacao de aplicacoesque executam em um espaco, respectivamente. Dentre os servicos do sistemadestacam-se o gerenciamento de estado, servico de invocacao, servico de des-coberta e o heap de dados. A seguir, descrevemos os tres servicos principaisdo middleware: heap de eventos, heap de dados e iCrafter.

16

Figura 2.3: Arquitetura iRoom.

2.3.1 Heap de eventos

O heap de eventos consiste no principal servico oferecido pelo middleware,uma vez que implementa a coordenacao dinamica das aplicacoes ativas emum espaco e forma a infra-estrutura de comunicacao subjacente. Derivadoda extensao de um modelo de espaco de tuplas, o heap de eventos armazenae direciona mensagens (eventos) representados por tuplas. Cada tupla, porsua vez, e uma colecao nomeada de pares atributo-valor.

Espacos de tuplas [16] consistem em modelos de coordenacao que se ca-racterizam pela dissociacao entre mecanismos de coordenacao e linguagemde programacao. Eles foram propostos com o objetivo de coordenar tare-fas paralelas. O modelo implementa tres primitivas para manipular tuplas:out, in e read. A primitiva out coloca uma tupla em um espaco abstrato,denominado espaco de tuplas, o qual e visıvel para todas as aplicacoes. Asoperacoes in e read removem ou copiam uma tupla, respectivamente. O de-sacoplamento entre mecansimo de coordenacao e linguagem de programacaoresulta em portabilidade, interoperabilidade e flexibilidade, requisitos essen-ciais para espacos interativos. Entretanto, algumas propriedades do modelode espaco de tuplas devem ser adaptadas para melhor atender as exigenciasde espacos interativos. Em particular, o heap de eventos do iROS, estendeo modelo de tuplas para permitir: i) tuplas auto-descritivas para adicionarsemantica aos eventos; ii)tipagem dos atributos que compoem uma tupla parafacilitar a construcao de filtros para recuperacao de enventos; iii) sequencia-mento de eventos, uma vez que o modelo de tuplas tradicional nao garantea ordem de entrega de mensagens; e iv) adicao de tempo de vida as tuplas.

Atualmente, o heap de eventos esta implementado sobre o TSpaces [17],um sistema de espacos de tuplas da IBM baseado em Java. TSpaces se-gue o modelo cliente-servidor e o estado atual das tuplas e armazenado emuma maquina servidora. O heap de eventos forma entao uma camada decomunicacao entre o espaco de tuplas (TSpaces server) e as aplicacoes que

17

o utilizam. Como mostrado na figura 2.4, um cliente iROS deve instanciar aversao TSpace client e uma instancia do heap de eventos. Aplicacoes podeminteragir com o heap de eventos atraves de varias APIs, incluindo web, Javae C++.

Figura 2.4: Heap de eventos.

2.3.2 Heap de dados

O heap de dados facilita a movimentacao de dados ao permitir que qualqueraplicacao os armazene em um repositorio associado com o ambiente local.Os dados sao armazenados juntamente com descritores (meta-dados) que osdescrevem. Um exemplo de meta-dado consiste no formato do dado, in-formacao usada pelo heap de dados para carregar automaticamente o plug-inapropriado para tranformar o dado de acordo com a necessidade da aplicacaorequisitante.

18

2.3.3 iCrafter

iCrafter e uma ferramenta atraves da qual usuarios criam e gerenciam servicos.Para tanto, ela prove uma infra-estrutura de servico denominada gerenciadorde interface. Servicos criados pelo iCrafter podem ser controlados, atravesde codigo, pela aplicacao, ou controlado diretamente pelo usuario.

2.4 Oxygen

Oxygen [18] e um projeto em desenvolvimento na universidade do MIT, cujoobjetivo e concentrar um conjunto de usuarios e tecnologias de comunicacaopara prover cenarios de computacao ubıqua centrados no usuario, enfatizandoa construcao de ambientes inteligentes capazes de antecipar e responder asnecessidades dos usuarios de um espaco. Mais especificamente, o objetivo doprojeto e prover acesso aos recursos de um ambiente atraves de tecnicas devisualizacao e reconhecimento de voz. Para isto, a abordagem adotada noprojeto divide o espaco em tres categorias (figura 2.5): dispositivos portateis(H21), rede de comunicacao (N21) e um ambiente monitorado por sensores(E21). Este espaco e coordenado por um middleware denominado MetaGlue,o qual consiste em uma plataforma robusta de agentes, onde agentes repre-sentam recursos disponıveis, interacoes entre tais recursos e um conjunto detecnicas de inteligencia artificial. Contudo, MetaGlue nao prove nenhumsuporte a ciencia de contexto. Este servico e responsabilidade de um ou-tro componente Oxygen denominado GOALS. A seguir descrevemos as duasprincipais infra-estruturas de servico de Oxygen.

2.4.1 MetaGlue

MetaGlue [19] consiste em um middleware baseado em agentes destinadoa construcao de aplicacoes interativas e distribuıdas que executam em am-bientes inteligentes. Ele prove um conjunto de servicos que estendem asfuncionalidades de um espaco, facilitando a interacao com o usuario. Paradisponibilizar tais servicos, MetaGlue se apoia em uma linguagem de pro-gramacao que estende a linguagem Java, fornecendo primitivas para tratarrequisitos como gerenciamento de configuracao, comunicacao entre agentes,controle de estado dos agentes, gerencia de recursos compartilhados e noti-ficacao de eventos. Cada um destes servicos e implementado por um ou maisagentes que executam sobre uma maquina virtual MetaGlue, que, por suavez, executa sobre a maquina virtual de Java.

O estado interno dos agentes sao armazenados em um banco de dadosinterno do middleware. Isto facilita a configuracao ou reconfiguracao dos

19

Figura 2.5: Visao de um espaco interativo em Oxygen

agentes, uma vez que o estado interno dos mesmos nao esta encapsuladono seu codigo. Primitivas de congelamento e descongelamento sao ofereci-das para, respectivamente, salvar e recuperar o estado de um agente. Partedeste estado consiste em um conjunto de atributos que caracteriza os requi-sitos necessarios para que o agente execute seu servico. Assim, ao instanciarum agente, o middleware o faz em uma maquina capaz de satisfazer taisexigencias. Este servico de configuracao permite que agentes possam mi-grar em virtude de falhas, balanceamento de carga ou necessidade de novosrecursos nao disponıveis na maquina local.

Todo agente MetaGlue executa uma funcionalidade e, portanto, umaaplicacao e composta por diversos agentes que interagem entre si para comporo comportamemto desejado. Agentes se conectam a outros agentes atravesde uma primitiva de associacao que leva em conta o servico fornecido. Assim,quando um agente e instanciado, ele exporta o nome do seu servico e o en-dereco da maquina virtual em que executa para um catalogo. Quando umaprimitiva de associacao e executada, ela procura pelo servico requisitado nocatalogo e devolve uma referencia para o agente responsavel pelo servico.

Alem da possibilidade de agentes se interagirem diretamente atraves dechamadas remotas, MetaGlue oferece tambem um mecanismo de notificacaode eventos. Agentes podem se registrarem neste mecanismo para serem notifi-cados sobre eventos no sistema. Em geral, o servico de notificacao de eventos

20

e usado para notificar agentes sobre mudancas no contexto. O servico decontexto e decrito a seguir.

2.4.2 GOALS

GOALS [20] consiste em um middleware reflexivo, no qual o meta-nıvel edefinido como uma camada de planejamento para a camada do nıvel base,denominada camada de computacao. Na camada de planejamento, objetivos(ou goals) sao formalizados como uma construcao de liguagem e usados paraguiar a composicao e adaptacao de aplicacoes. Sintaticamente, objetivossao similares a chamadas de procedimento: eles sao invocados atraves deum nome generico de servico seguido de alguns parametros. Entretanto,diferentemente de chamadas de procedimento, objetivos sao desacoploadosde blocos de codigo. A resolucao de um objetivo e entao aproximada porum objeto do sistema, denominado contexto. Este objeto e responsavel porprocurar por uma ou mais tecnicas (ou technique) capaz de resolver umaclasse de objetivos. Cada tecnica especifica: um padrao que deve se casarcom um determinado objetivo, um conjunto de sub-objetivos que devem sersatisfeitos para que a tecnica proceda e um bloco de codigo a ser executadopara satisfazer o objetivo. Portanto, a satisfacao de um objetivo envolveos seguintes passos: a enumeracao das tecnicas candidatas a solucao de umobjetivo, a avaliacao de cada tecnica candidata, a selecao da tecnica maisapropriada, baseando-se em heurısticas, e a execucao do plano escolhido.Como uma tecnica pode necessitar que alguns sub-objetivos sejam satisfeitos,a solucao de um objetivo pode gerar uma arvore de objetivos e sub-objetivosa serem analisados. Uma solucao pode ser vista, entao, como um caminhonesta arvore.

2.5 EasyLiving

EasyLiving [21] e um projeto iniciado na Microsoft cujo objetivo e inves-tigar como construir inteligencia em ambientes ubıquos. Neste projeto, acoordenacao do ambiente e feita atraves de um middleware, denominado In-Concert, o qual consiste de um conjunto de agentes representando os objetosde interesse de um espaco. Um agente InConcert e composto por um processoe um conjunto de propriedades. Estas ultimas sao armazenadas em banco dedados para facilitar a configuracao e reconfiguracao do estado de um agente.

Como mostrado na figura 2.6, EasyLiving e composto por quatro modulosprincipais: monitoramento de pessoas, modelo do mundo, controle do ambi-ente e autenticacao. Estes modulos se comunicam entre si atraves de mensa-

21

Figura 2.6: Arquitetura EasyLiving

gens assıncronas baseadas em XML. O modulo de monitoramento de pessoasprove um servico de presenca que notifica a entrada ou saıda de pessoasdo ambiente monitorado, bem como a identificacao de alguns gestos por elasrealizados. O modelo do mundo consiste de um modulo que descreve os dispo-sitivos (quais sao, onde estao localizados, status e proxy) e servicos presentesno ambiente. Para tanto, implementa dois servicos: servico de lookup e umsistema de identificacao de dispositivos. O primeiro oferece enderecamentode recursos independente de maquina. Quando inicializada, a instancia deum componente requisita um identificador, o qual e enviado periodicamentepara o servico de lookup atraves de uma mensagem de heartbeat. Ao rece-ber tal mensagem, o servico de lookup tem conhecimento da localizacao docomponte. Quando o middleware tem que rotear mensagens, ele consulta oservico de lookup para obter o endereco do destino.

O sistema de identificacao de dispositivos e usado para automatizar a de-teccao dos dispositivos existentes no ambiente. Para isto, tal servico utilizaum modelo de localizacao baseado em informacoes geometricas de pessoase dispositivos, coletadas por sensores. As informacoes coletadas por esteservico sao usadas pelo modulo de controle do ambiente para automatizar aselecao de dispositivos para uma determinada interacao. Como esta automa-tizacao e baseada na percepcao do ambiente, uma maquina de inferencia deregras se faz necessaria para diminuir o grau de incerteza das previsoes.

Cada dispoistivo do ambiente e representado no sistema atraves de umproxy agent. Este proxy e responsavel por gerenciar a comunicacao entre o

22

dispositivo e o resto do sistema (outros proxy, agentes ou aplicacoes). Umdescritor XML descreve o conteudo das mensagens trocadas.

23

Capıtulo 3

Comparacao e Conclusoes

Neste capıtulo, os cinco projetos estudados no capıtulo anterior sao com-parados entre si em relacao aos criterios definidos no capitulo 1, divididosem tres grupos: aspectos gerais, tecnologia utilizada e servicos implemen-tados. Em relacao a aspectos gerais, os projetos estudados sao comparadosconsiderando-se o grupo empreendedor do projeto, data de inıcio e seu ob-jetivo/motivacao principal. Em relacao a tecnologia, analisamos os projetossegundo o paradigma de programacao adotado, plataformas e linguagens deprogramacao suportadas e modelo de comunicacao utilizado. Em relacao aosservicos, os projetos estudados sao analisados considerando-se aos servicosbasicos providos por infra-estruturas de suporte a computacao ubıqua descri-tos no capıtulo 1. A Secao 3.1 sintetisa o resultado deste estudo comparativo,enquanto que a Secao 3.2 apresenta algumas conclusoes.

3.1 Estudo comparativo

3.1.1 Aspectos Gerais

Gaia e um projeto desenvolvido na universidade de Urbana-Champaign queteve inıcio no ano 2000. O objetivo principal do projeto e investigar espacosativos atraves de uma perspectiva de sistema operacional que executa so-bre sistemas operacionais e dispositivos heterogeneos existentes e expor umaabstracao comum deste espaco fısico. Alguns prototipos foram desenvolvi-dos para utilizar a infra-estrutura oferecida, particularmente aplicacoes parasalas inteligentes.

one.world e um projeto desenvolvido pela universidade de Washington eteve inıcio no ano 2004. O objetivo principal do projeto e investigar cenariospara computacao ubıqua, assumindo-se ambientes altamente dinamicos, partindo-

24

se de aplicacoes projetadas essencialmente para usar sua infra-estrutura. Umprototipo para um laboratorio de experimentos biologicos foi implementadopara avaliar a arquitetura e servicos implementados.

iRoom e um projeto da universidade de Stanford que teve inıcio em1999. O objetivo principal do projeto consiste em investigar espacos inte-rativos para grupos de trabalho atraves do mapeamento de um unico espacofısico para um conjunto de hardware e software incorporados pelo ambiente,enfatizando-se modelos de interacao. O projeto foi validado atraves de umprototipo de uma sala de aula inteligente.

Oxygen e um projeto multidisciplinar da universidade do MIT, inici-ado em 1999. Seu objetivo principal e acrescentar inteligencia a ambientesubıquos, usando tecnicas de IA (inteligencia artificial) para prover acessoaos recursos destes ambientes. Os prototipos desenvolvidos no projeto sedestinam a salas de aula e reunao inteligentes.

EasyLiving e o unico projeto estado cuja origem nao esta relacionadaa um ambiente academico. Desenvolvido pela Microsolft, este projeto teveinıcio no ano 2000 com o objetivo de experimentar ambientes domesticosinteligentes. O projeto enfatiza o monitoramento de pessoas e dispositivosatraves de sua localizacao fısica em um determinado ambiente, utilizandoesta informacao para definir modelos de interacao mais apropriados para ousuario.

3.1.2 Tecnologia

Em relacao ao paradigma de programacao adotado, Gaia, one.world e iRoomsao infra-estruturas baseadas em componentes de software. Assim, a prin-cipal abstracao de servico fornecida pelo middleware e atraves de compo-nententes de software. Componentes Gaia sao objetos CORBA enquantoque componentes one.world e iRoom sao objetos Java. Oxygen e Easy-Living, por sua vez, sao infra-estruturas baseada em agentes e, portanto,aplicacoes desenvolvidas para estes projetos consistem em um conjunto deagentes que interagem entre si para implementar um comportamento dese-jado. Agentes Oxygen sao implementados em Java enquanto que agentesEasyLiving sao implementados em .NET. Com excecao de EasyLiving, to-dos os projetos suportam varias plataformas (unix, linux e windows). Gaiae iRoom suportam varias linguagens de programacao (Java, C++ e web).one.world e Oxygen suportam apenas Java e EasyLiving apenas .NET. Emrelacao ao modelo de comunicacao adotado, Gaia permite comunicacao di-reta entre objetos atraves do protocolo CORBA IIOP ou subscricao atravesdo servico de eventos de CORBA. one.world, por sua vez, so admite comu-nicacao atraves de eventos, portanto o modelo de comunicacao e baseado

25

em publicacao/subscricao a eventos. EasyLiving implementa um modelo depassagem de mensagens assıncronas baseadas em XML. Oxygen utiliza ummodelo de publicacao/subscricao, porem agentes podem tambem se comuni-car atraves de RMI. Em iRoom, o modelo de comunicacao adotado e baseadoem espacos de tuplas.

3.1.3 Servicos

Todos os projetos estudados neste trabalham vislubram uma infra-estruturade apoio, oferecida como um conjunto de servicos basicos compostos porpequenas unidades de servico que se compoem para obter um comportamentodesejado. Neste sentido, dois servicos se tornam essenciais: instanciacaoe configuracao automatica. Afim de tornar tais servicos mais simples, oscinco projetos aqui estudados adotam alguma abordagem de descricao de seuscomponentes/agentes. Assim, Gaia descreve seus componentes atraves de umreposıtorio de componentes e repositorio de interfaces. Entretanto, Gaia, aocontrario dos demais projetos, nao fornece nenhuma forma de armazenar oestado interno de um componente de forma explıcita. Em one.world, tuplasauto-descritivas podem ser armazenadas e recuperadas de ambientes atravesdo servico de gerenciamento de dados. Adicionalmente, o estado de umaaplicacao tambem pode ser salvo atraves de checkpoints. De maneira similar,iRoom, permite uma dissociacao entre o comportamento de um componentee seu estado atraves do heap de dados. EasyLiving e Oxygen (MetaGlue)implementam requisito similar, armazenando o estado do agente em bancosde dados.

Em relacao ao servico de descoberta, Gaia nao implementa nenhum servicoautomatico e se apoia no servico de nomes de CORBA. EasyLiving e Oxygentambem utilizam um servico de lookup estatico, baseado no ID e nome doservico, respectivamente. Em one.world e iRoom servicos sao descobertosnao pelo seu nome, mas sim pela seus atributos e em tempo de execucao.

O servico de contexto, e, portanto, a capacidade de adaptacao, esta pre-sente nos cinco projetos estudados. Em Gaia, este servico e baseado em umpoderoso modelo de logica de primeira ordem e algebra boleana. Em Easy-Living este servico e implementado pelo modelo de localizacao geometricoque representa informacoes sobre o relacionamento fısico entre pessoas, dis-positivos e objetos do mundo. Em Oxygen este servico e implementado pelomodelo de planemamento (planning) de GOALS. Em one.world e iRoom,a arquitetura do sistema foi concebida de forma a tratar eventos como da-dos (mensagens) trocados entre componentes e entre componentes e o mid-dleware, de forma que o proprio modelo de comunicacao serve tambem parao servico de contexto. E importante observar que o criterio de adaptabili-

26

dade foi considerado dentro da otica do servico de contexto provido pelosmiddlewares estudados.

Em relacao a escalabilidade, a intensao de Gaia de construir um sistemaoperacional para abstrair um ambiente comum entre diversos dispositivos he-terogeneos dificulta a escalabilidade do sistema. De maneira similar, a opcaopor economia de mecanismos e a escolha por solucoes centralizadas tomadasem iRoom tambem tornam este projeto pouco escalavel. Oxygen faz uso daestrutura robusta de MetaGlue que se mostra aparentemente escalavel, em-bora uma analise que exija maior escalabilidade do sistema ainda nao tenhasido realizada. Dentre as infra-estruturas estudas, one.world apresenta a ar-quitetura mais escalavel, uma vez que este fez a opcao por uma arquiteturaprojetada especialmente para atender aos requisitos essenciais de aplicacoesubıquas, sem compromisso com aplicacoes legadas.

Em relacao a tolerancia a falhas e importante notar que, dos projetosestudados, poucos oferecem continuidade de servico diante de falhas. Gaianao possui servicos de tolerancia a falhas, enquanto que Oxygen, iRoom eEasyLiving proveem um servico parcial. Em iRoom, o heap de eventos im-plementa um mecanismo rapido de reinicializacao que, aliado ao desacopla-mento do mecanismo de comunicacao (que nao exige que ambos os extremosda comunicacao estejam ativos para que a mesma proceda) prove um meca-nismo parcial de tolerancia a falhas. De forma similar, Oxygem e EasyLivingarmazenam o estado dos agentes em bancos de dados, o que favorece um me-canismo de recuperacao simples. Em one.world, o servico de checkpoint emigracao implementam um mecanismo sofisticado de tolerancia a falhas.

As tabelas 3.1, 3.2 e 3.3 resumem esta discussao. O termo TF na tabela3.3 representa Tolerancia a Falhas.

Middleware Criterio: Aspectos GeraisGrupo Inicio Objetivo

Gaia Urbana-Champaign 2000 heterogeneidade emdiferentes espacos

one.world Washington 2004 dinamicidade emdiferentes espacos

iRoom Stanford 1999 interatividade emespacos para grupos de trabalho

Oxygen MIT 1999 inteligencia emespacos para grupos de trabalho

EasyLiving Microsot 2000 inteligencia emambientes domesticos

Tabela 3.1: Comparacao segundo aspectos gerais

27

Middleware Criterio: TecnologiasParadigma Plataformas Linguagens Modelo de

Comunicacao

Gaia componentes varias varias CORBA IIOPservico de eventosde CORBA

one.world componentes varias Java publicacao/subscricaoiRoom componentes varias Java,C++,web espaco de tuplasOxygen agentes varias Java RMI

publicacao/subscricaoEasyLiving agentes windows .NET mensagem assıncrona

baseada em XML

Tabela 3.2: Comparacao segundo aspectos tecnologicos

Middleware Criterio: ServicosInstanciacao Descoberta Contexto Esca TFConfiguracao labilidade

Gaia automatico servico de expressivo nao naonomes de CORBA

one.world automatico dinamico pouco expressivo sim simbaseado em atributos

iRoom automatico dinamico pouco expressivo nao parcialbaseado em atributos

Oxygen automatico estatico expressivo sim parcialbaseado no nome

EasyLiving automatico estatico expressivo - parcial

Tabela 3.3: Comparacao segundo aspectos de servicos

3.2 Conclusao

Este trabalho teve como objetivo investigar infra-estruturas de software ne-cessarias para computacao ubıqua. Em geral, tratamos a necessidade demiddlewares para permitir o projeto e execucao de aplicacoes ubıquas quese interagem e compartilham recursos num ambiente repleto de dispositivosheterogeneos voltados para interacao. Mais especificamente, cinco projetosforam estudados e comparados entre si. Enquanto um conjunto basico de

28

servicos eram providos por todos os projetos estudados, eles se diferencia-vam essencialmente em relacao aos objetivos propostos, paradigma de pro-gramacao utilizado e modelo de comunicacao suportados. E importante no-tar, entretanto, que, apesar dos projetos escolhidos representarem um con-junto substancial do estado da arte no suporte a aplicacoes ubıquas, elesainda consistem em arquiteturas projetadas para objetivos especıficos e nor-malmente limitados ao controle de poucos ambientes, sofrendo portanto deproblemas de generalizacao, escalabilidade e robustez. Adicionalmente, pou-cos prototipos foram desenvolvidos para explorar mais efetivamente as poten-cialidades das arquiteturas aqui descritas. Tudo isto nos permite concluir quea area de computacao ubıqua esta apenas comecando e que varias questoesimportantes ainda representam grandes desafios.

29

Referencias Bibliograficas

[1] M. Weiser, “The Computer for the 21st Century,” Scientific American,1991.

[2] U. Ramachandran, G. Abowd, M. Modahl, B. Agarwalla, and S. Sapo-nas, “Toward a Standad Ubiquitous Computing Framework.,” In Proce-edings of 2nd Workshop on Middleware for Pervasive and AdHoc Com-puting, 2004.

[3] Y. Goland, T. Cai, P. Leach, and Y. Gu . IETF Internet Draft: Simpleservice discovery protocol/1.0, 1999.

[4] Bellwood and et al . UDDI version 2.03 data structure reference, 2002.

[5] M. Gudgin, A. Lewis, and J. Schlimmer . W3C Working. Draft: Webservices description language (wsdl) version 2.0 part 2: Message ex-change patterns, 2004.

[6] M. Roman, C. K. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell,and K. Nahrstedt, “Gaia: A Middleware Infrastructure to Enable ActiveSpaces.,” IEEE Pervasive Computing, pp. 74-83, 2002.

[7] M. Roman, C. K. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell,and K. Nahrstedt, “Gaia: A Middleware Infrastructure to Enable ActiveSpaces.,” Technical Report., 2002.

[8] M. Henning and S. Vinosky, “Advanced CORBA Programming withC++,” Addison-Wesley, 1999.

[9] A. K. Dey and G. Abdowd, “The Context Toolkit: Aiding the Develop-ment of Context-Aware Applications,” Workshop on Software Enginee-ring for Wearable and Pervasie Computing, 2000.

[10] G. Krasner and S. Pope, “A Description of the Model-View-ControllerUser Interface Paradigm in the Smalltalk-80 System,” ParcPlace Sys-tems, 1988.

30

[11] R. Grimm, J. Davis, E. Lemar, A. Macbeth, S. S., T. Anderson,B. Bershad, G. Borriello, S. Gribble, and D. Wetherall, “System Supportfor Pervasive Applications.,” ACM Transactions on Computer Systems,2004.

[12] R. Grimm, “System Support for Pervasive Applications.,” PhD Thesisand University of Washington, 2004.

[13] B. Johanson, A. Fox, and T. Winograd, “The Interactive WorkspackesProject: Experiences with Ubiquitous Computing Rooms.,” PervasiveComputing, 2002.

[14] B. Johanson, “Application Coordination Infrastructure for UbiquitousComputing Rooms.,” PhD Thesis and University of Stanford, 2002.

[15] S. Ponnekanti, “Portability, Extensibility and Robustness in iROS.,”First IEEE International Conference on Pervasive Computing and Com-munications, 2003.

[16] S. Ahuja, N. Carriero, and D. Gelernter, “Linda and Friends,” IEEEComputer, 1986.

[17] P. Wyckoff, S. McLaughry, T. Lehman, and D. Ford, “TSpaces. IBMSystems,” Journal 37(3), 2000.

[18] L. Rudolph, “Project Oxygen: Pervasive, Human-Centric Computing:An Initial Experience,” Advanced Information Systems Engineering,13th International Conference (CAiSE2001), 2001.

[19] M. H. Coen, B. Phillips, N. Warshawsky, L. Weisman, S. Peters, andP. Finin, “Meeting the Computational Needs of Intelligent Environ-ments: The Metaglue System,” Proceedings of MANSE’99, 1999.

[20] e. a. Saif, U., “A Case for Goal-oriented Programming Semantics.,” Ubi-comp, 2003.

[21] B. Brumitt, B. Meyers, J. Krumm, A. Kern, and S. Shafer, “Easyliving:Technologies for intelligent environments.,” Proceedings of the 2nd In-ternational Symposium on Handheld and Ubiquitous Computing, 2000.

31