Frameworks e Middleware para Computação Ubíqua

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çãoe 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) • lEmcee: 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.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.

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