Frameworks e Middleware
para Computação Ubíqua
MAC 5743
2o. Semestre de 2004
Fernando A. de Sousa
Road Map

Definição de conceitos básicos
Framework
 Middleware
 Computação Ubíqua


Mas o que é mesmo essa tal de
computação ubíqua?
Breve histórico e proposta – Mark Weiser
 Infra-estrutura
 Problemas

Road Map

Projetos de Computação Ubíqua
Gaia
 One.world
 Aura


Referências
Conceitos Básicos
O
que é Framework?
Pacotes de software que fornecem uma solução genérica para um
determinado domínio de aplicação. Um framework define um
projeto abstrato para soluções de problemas de uma família de
aplicações dentro de um domínio.
O
que é Middleware?
Camada de software que não constitue diretamente uma
aplicação, mas que é intermediária entre a camada da mesma e o
ambiente de execução. A camada de middleware concentra
serviços diversos cuja função é facilitar o desenvolvimento.
Conceitos Básicos
 Computação
Ubíqua
Computação Pervasiva ou Computação Ubíqua é o termo utilizado
para referenciar a integração da computação móvel e onipresente
com o espaço físico. É um tipo de computação distribuída
realizada por dispositivos de computação que atuam de forma
discreta nos ambientes onde estão implantados
Computação Ubíqua x Realidade Virtual
Idéias Opostas: Uma baseia-se na inserção do homem em uma
realidade simulada e a outra procura inserir e adaptar novos
elementos à realidade humana.
Mas o que é mesmo essa tal
Computação Ubíqua?

Idealizada por Mark Weiser que imaginou
ambientes impregnados de computação,
nos quais os dispositivos estão totalmente
adaptados ao cotidiano.
 Ambientes: espaços físicos quaisquer –
salas de aula, escritórios, edifícios.
 Calm Technology: a integração é tranqüila
e até imperceptível (computação
invisível).
O que é mesmo essa tal
Computação Ubíqua?

Principais Características:
Onipresença
 Adaptação
 Sistemas Distribuídos e Intuitivos

- Contexto e Comunicação

Mudança na relação homem – máquina
(o papel do homem passa a ser mais passivo
x
computador deixa de ser o foco das atenções)
Infra-estrutura

Taxonomia de subsistemas ou serviços

Definida pela
equipe do
Georgia Tech
www.cc.gatech.edu

A idéia de utilizar
camada de middleware para conseguir
minimizar o problema da heterogeneidade.
Taxonomia de subsistemas

Registro e Descoberta



Registro, remoção e pesquisa de recursos
ou serviços
Aspectos considerados para as operações
(palavra-chave, tipo, subtipo, fornecedor,
custo; contexto – localização,
conectividade, reserva de energia, etc.)
Elementos de diferentes abstrações podem
ser registrados e descobertos
(equipamentos, serviços, usuários...
Qualquer objeto)
Taxonomia de subsistemas

Serviço e Assinatura (assinatura de serviços)

Clientes assinam serviço disponibilizado

Intermediação:


Encapsula características de provedor de
serviços propiciando interoperabilidade, troca de
provedores, serviços distribuídos
(balanceamento de carga, redução de latência,...)
Requisitos:




Interface Extensível
Escalabilidade
Transparência em relação à rede
Eficiência: rápida transferência de mensagens
Taxonomia de subsistemas

Armazenamento e envio de dados seriados



Coordenação da transferência e
armazenamento distribuído de grandes
estruturas de dados
Torna transparente o espalhamento, a
redundância, a replicação
Resolve alguns problemas de conectividade,
disponibilidade e latência
Taxonomia de subsistemas

Compartilhamento de Recursos


Objetivo de tentar diminuir a subutilização de
recursos computacionais
Funções básicas:





Procurar recursos adequados
Alocar e desalocar recursos
Contabilizar o uso
Implementar políticas de utilização
Delegação de processamento sensível ao nível
de energia
Taxonomia de subsistemas

Gerenciamento de Contexto
Fornecem uma abstração do contexto e
linguagem
 Possível dependência de sensores
 Requisitos:

Linguagem simples e poderosa
 Inferência de fatos de nível mais alto

Problemas

Alguns dos desafios e problemas enfrentados
pela UC:







Tentar fazer das UCAs killer applications
Criar sistemas tolerantes a falhas
Interoperabilidade
Sensibilidade ao Contexto
Garantir Privacidade
Custo dos dispositivos computacionais
Baixo consumo de energia
Projeto Gaia
Universidade de Illinois


Origem : Projeto 2K – também da Univ. de Illinois
2K tem origem no Choices
Projeto Gaia - Origens

Choices






Um dos primeiros SODs
Orientado a objetos – flexibilidade, extensibilidade
Queriam provar que é possível construir um S.O. em C++
Arquitetura geral é definida como um framework
Exokernel: radicalização da idéia de microkernel
2K


Motivação: construir um Choices distribuído para a Internet
Abordagem: middleware-level OS

Para resolver a questão da heterogeneidade de hardware
e software / alguns problemas por causa da
inflexibilidade e peso das plataformas
Projeto Gaia
Estender as idéias do 2K para
computação Ubíqua: um SO para
espaços ativos.
 Espaço Ativo: Ambiente de computação
composto por um espaço físico qualquer
enriquecido com dispositivos eletroeletrônicos capazes de realizar algum
tipo de computação útil aos
freqüentadores do ambiente.

Projeto Gaia

Arquitetura do Gaia:
Projeto Gaia - GaiaOS

1) Alguns dos Serviços do Kernel



Gerenciador de Eventos: distribuir informações
entre os componentes mantendo o fraco
acoplamento
Repositório do Espaço: interface para a busca de
entidades específicas baseadas em condições
como localização, tipo de serviço e disponibilidade
de recursos.
Serviço de Autenticação e Controle de Acesso:
utilização de credenciais e papéis (perfis).
Projeto Gaia - GaiaOS

2) Unified Object Bus



provê ferramentas para manipular uniformemente
componentes heterogêneos que estão executando no
sistema.
Manipulação do ciclo de vida dos componentes de sistema
e de aplicação
Define 4 abstrações básicas: “Unified Component”,
“Component Manager”, “Component Container” e o
UOBHost.
Componente Unificado: são os elementos básicos
do UOB. Seguem um esquema de nomenclatura
comum e seu ciclo de vida pode ser gerenciado
dinamicamente independentemente de seu modelo
de componentes e sua localização .
Projeto Gaia - GaiaOS

2) Unified Object Bus



Gerenciador de Componentes: determina a interface para
manipular o ciclo de vida de componentes e encapsula a
funcionalidade de integrar diferentes modelos de
componentes; entretanto há um gerenciador para cada
modelo de componentes integrado.
Component Container: provê o ambiente de execução
para os componentes e determina a funcionalidade de
gerenciar as dependências dos componentes que contém.
UOBHost: qualquer dispositivo capaz de hospedar a
execução de componentes. Determinam a funcionalidade de
criar, remover Component Containers, bem como criar
componentes em containers específicos.
Projeto Gaia – Modelo de Aplicações



Framework padrão para aplicações ubíquas
MVC para Espaços ativos: MPACC
Model – O modelo é a implementação da estrutura
central da aplicação, que normalmente consiste nos
dados e na interface programável para manipulá-los.
Projeto Gaia – Modelo de Aplicações

Presentation – É a externalização física do modelo que
permite aos usuários percebê-lo através de um ou mais
sentidos.
 Adapter – É o componente responsável por adaptar o
formato dos dados do modelo às características de um
dispositivo de saída.
 Controller – Determina mecanismos para modificar o estado
do modelo. Entretanto, diferentemente do controlador
padrão do MVC, o controlador definido pelo MPACC
coordena não apenas os dispositivos de entrada, mas
qualquer origem de contexto físico e digital que pode afetar
a aplicação.
 Coordinator – O coordenador é um componente de metanível que gerencia a composição da aplicação e aplica
políticas de adaptação baseadas nos aspectos funcionais e
não funcionais da aplicação.
Projeto One.world
Projeto One.world

Metodologia de design
Foco nos requisitos de aplicações
pervasivas
 Explorar requisitos mal atendidos nos
sistemas contemporâneos
 Definir uma arquitetura de sistema que
atenda bem tais requisitos
 Validação com a construção de aplicações
 Iteração

Projeto One.world

Pontos Importantes:



Aceitar a mudança de contexto – é impraticável
considerar isso problema do usuário
Encorajar composição Ad Hoc – usuários
esperam que dispositivos e aplicações
“pluguem” juntos.
Compartilhamento é default – as aplicações
precisam compartilhar facilmente a informação
através do tempo e dos dispositivos
One.world - Arquitetura
Projeto One.world – Características
Executa sobre a JVM
 O conceito de Ambientes:



Agem como espaços de endereços,
armazenam dados persistentes, facilitam
composição e migração
Eventos

Tornam as mudanças explícitas para a
aplicação.
Projeto One.world - Cenário
One.world – Serviço de Descoberta

Mecanismo de Rendezvous: encontrar
recursos com localização desconhecida ou em
constante alteração
 Provê um serviço de lookup que mapeia
descrições de recursos à handlers de eventos
 Eleições (auto-gerenciamento):



Servidor se anuncia periodicamente através de
broadcasts UDP
Eleição é convocada quando detecta-se 2 anúncios
perdidos, quando o servidor falha ou quando a
máquina é desligada
Algoritmo de eleição simples
One.world – Outros destaques

Migração: cópia ou movimentação de ambientes
e todo o seu conteúdo (operação atômica)

Emcee: Gerenciamento de usuários
e aplicações.
Shell gráfico com interface drag
and drop para o gerenciamento
dos ambientes (árvore)
Depende do serviço de migração e do
serviço de descoberta
Faz um scan do ambiente de destino para
detectar a chegada da aplicação
Projeto Aura
Carnegie Mellon University
Projeto Aura - Objetivos

Prover ao usuário um ambiente de
computação invisível, particular e repleto de
serviços, que o acompanha onde quer que ele
vá: sua Aura.
 Redução da exigência da atenção do usuário
(lei de Moore)
 Conseguir escalabilidade para cenário com
usuários móveis em um ambiente propenso a
falhas e com variabilidade de recursos
Projeto Aura...?

Desenvolvimento em todos os níveis:
Camadas de hardware e rede
 Sistema operacional e middleware
 Interface de usuário e aplicações


Projetos paralelos o compõe:

Coda: sistema de arquivos distribuído que
apresenta replicação, segurança, tolerância
a falhas, adaptação às mudanças de
largura de banda
Projeto Aura - Composição

Projetos paralelos o compõe:
Odissey: extensão do sistema operacional
que é responsável pela adaptação,
sensibilidade a contexto – monitora
recursos.
 Spectra: mecanismo adaptativo para
execução de chamadas remotas – também
há sensibilidade ao contexto

Projeto Aura - Arquitetura
Projeto Aura – Alguns destaques

Pró-atividade / auto ajuste


tentativa de inferir requisições de uma camada mais
alta. As camadas adaptam-se ajustando a sua
performance e o uso de recursos observando a
demanda – fatores que colaboram para reduzir a
necessidade de atenção do usuário
Gerenciador de Tarefas - Prisma

Processos que estavam sendo executados
anteriormente podem ter que se adaptar a um novo
contexto – congelamento das aplicações e
restauração quando os recursos estão novamente
presentes
Projeto Aura – Task Manager
Outros Projetos de UC


Ninja (Berkeley)
Oxygen (MIT)
 Future Computing Environments (Georgia Tech)
 Pervasive Computing (IBM)
 Ubicomp (Universität Karlsruhe)
 Multimodal Interfaces (CMU)
 Portolano (UW)
 Ubiquitous Computing (Xerox Parc)
 Endeavour (Berkeley)
 Cooltown (HP)
 Easy Living (Microsoft)
Referências
Gaia Project: http://gaia.cs.uiuc.edu/
One.world: http://cs.nyu.edu/rgrimm/one.world/
Aura: http://www-2.cs.cmu.edu/~aura/





[AMCRC04] Jalal AlMuhtadi, Shiva Chetan, Anand Ranganathan, and Roy Campbell. Super
spaces: A middleware for largescale pervasive computing environments. In Proceedings of the
Second IEEE Annual Conference on Pervasive Computing and Communications Workshops,
page 198. IEEE Computer Society, 2004.
[DoCS] University of Illinois at UrbanaChampaign Departament of Computer Science. Gaia
project, active spaces for ubiquitous computing. http://gaia.cs.uiuc.edu. [dW] Universidade de
Washington. Projeto one.world. http://one.cs.washington.edu.
[ea04a] CarlFredrik et al. A contextaware middleware for applications in mobile ad hoc
envirnments. In Proceedings of 2nd Workshop on Middleware for Pervasive and AdHoc
Computing, pages 107--110. ACM Press, 2004.
[ea04b] Suskil K. Prasad et al. Syd: a middleware testbed for collaborative applications over
small heterogeneous devices and data stores. In Proceedings of the International Middleware
Conference, pages 352--371, Toronto, Canada, October 2004. Springer.
[Gri02] Robert Grimm. System Support for Pervasive Applications. PhD thesis, Washington
University, October 2002.
Referências







[HM04] Markus C. Huebscher and Julie A. McCann. Adaptive middleware for context aware
applications in smarthomes. In Proceedings of the 2nd workshop on Middleware for pervasive
and adhoc computing, pages 111--116. ACM Press, 2004.
[MMH04] Mirco Musolesi, Cecilia Mascolo, and Stephen Hailes. Adapting asynchronous
messaging middleware to ad hoc networking. In Proceedings of the 2nd workshop on
Middleware for pervasive and adhoc computing, pages 121--126. ACM Press, 2004.
[RAM + 04] U. Ramachandran, Gregory Abowd, Martin Modahl, Bikash Agarwalla, and Scott
Saponas. Toward a standad ubiquitous computing framework. In Proceedings of 2nd
Workshop on Middleware for Pervasive and AdHoc Computing, pages 135--139. ACM Press,
2004.
[RBH04] Peter Rigole, Yolande Berbers, and Tom Holvoet. Mobile adaptive tasks guided by
resource contracts. In Proceedings of the 2nd workshop on Middleware for pervasive and
adhoc computing, pages 117--120. ACM Press, 2004.
[RHC + 02] Manuel Rom’an, Christopher Hess, Renato Cerqueira, Anand Ranganathan,
Roy H. Campbell, and Klara Nahrstedt. A middleware infrastructure for active spaces. IEEE
Pervasive Computing, 1(4):74--83, 2002.
[SG02] Jo”ao Pedro Sousa and David Garlan. Aura: an architectural framework for user
mobility in ubiquitous computing environments. In Proceedings of the IFIP 17th World
Computer Congress TC2 Stream / 3rd IEEE/IFIP Conference on Software Architecture, pages
29--43. Kluwer, B.V., 2002.