Frameworks e Middleware para Computa

1
Frameworks e Middleware para Computação Ubíqua

• MAC 5743
• 2o. Semestre de 2004
• Fernando A. de Sousa

2
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

3
Road Map

• Projetos de Computação Ubíqua
• Gaia
• One.world
• Aura
• Referências

4
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.
5
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.
6
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).

7
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)

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

9
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)

10
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

11
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

12
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

13
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

14
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

15
Projeto Gaia

• Universidade de Illinois
• Origem Projeto 2K também da Univ. de Illinois
• 2K tem origem no Choices

16
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

17
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 eletro-eletrônicos capazes de
  realizar algum tipo de computação útil aos
  freqüentadores do ambiente.

18
Projeto Gaia

• Arquitetura do Gaia

19
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).

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

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

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

23
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
  meta-ní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.

24
Projeto One.world
25
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

26
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

27
One.world - Arquitetura
28
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.

29
Projeto One.world - Cenário
30
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

31
One.world Outros destaques

• Migração cópia ou movimentação de ambientes e
  todo o seu conteúdo (operação atômica)

l 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
32
Projeto Aura
Carnegie Mellon University
33
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

34
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

35
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

36
Projeto Aura - Arquitetura
37
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

38
Projeto Aura Task Manager
39
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)

40
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.washi
  ngton.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.

41
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 Roman, 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 Joao 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.