Fernando Alberto de Sousa nusp: 3286224



Baixar 153.81 Kb.
Página2/4
Encontro29.07.2016
Tamanho153.81 Kb.
1   2   3   4

2.8.2 Baixo Consumo de Energia

Um dos requerimentos básicos para os dispositivos pequenos, ubíquos também está relacionado ao baixo consumo de energia. Os usuários não estarão dispostos a trocar baterias de centenas de dispositivos com frequência. O computadores de preço baixo vão precisar de baterias baratas, economicas e vão usar componentes de baixo consumo.

A carência de largura de banda

Um dos requerimentos necessários para que a computação ubíqua se torne lugar comum é a largura de banda de rede suficiente para permitir que centenas de dispositivos sejam capazes de se comunicar uns com os outros. Atualmente, ainda estamos nos estágios primários de rede, mas a medida que o tempo passa, o mundo baseado na comunicação por voz está cada vez mais, migrando para fibra ótica e redes sem fio. Para se ter uma idéia dos requerimentos de rede que serão necessários, um estudo recente do MCI estimou que o atual tráfego de dados em rede vai ultrapassar o tráfego de voz nos próximos três anos, com tendências de aumento ainda maior para os anos seguintes.

Mobilidade

A mobilidade é outro aspecto relacionado a computação ubíqua. Os usuários têm que ter computadores portáteis, com acesso sem fio a Internet, a partir de qualquer ponto de acesso.


2.8.3 Mobile IP

O Internet Protocol (IP) assume que a localização e a conexão de um computador permanece fixa. Um aspecto da atual pesquisa em computação móvel é na área de protocolos como o Mobile IP que é uma extensão do IP que possibilita os computadores se conectarem a partir de diversos pontos de acesso e mantendo o mesmo endereço IP.

Necessidade de conscientização do usuário para com sistemas de arquivo

Uma das primeiras coisas que os usuários precisam aprender no novo computador é sobre o conceitos de arquivos, e a hierarquia de diretórios que eles contem. Ao invés de concentrar na informação que eles têm disponível, o usuário é forçado a pensar em termos de como a informação está armazenada. Como consequência, a informação é armazenada de forma não intuitiva fazendo com que o usuário perca o rastro de localização dos arquivos, sobreponha novas versões de arquivos por versões antigas, exclua diretórios que contenha arquivos importantes, por acidente etc. Qualquer usuário de computador tem sua própria história aterrorizadora sobre exclusão acidental de arquivos, e quase na maioria das vezes, quando recuperáveis, acabaram resultando em perda de dados devido a natureza dos sistemas de arquivo.

Uma das idéias chaves da computação ubíqua é a de que os computadores devem se tornar invisíveis, e que eles têm que fornecer informações aos usuários na própria linguagem de usuário. Por exemplo, quando o usuário deseja trabalhar com um relatório do dia anterior, eles não deveriam ser forçados a lembrar de alguma coisa tal como “~/report.txt”, ou “C:\report.txt”, uma vez que isso seria forçar o usuário a pensar usando linguagem do computador. Seria mais simples para o usuário, se ele pudesse dizer em voz alta “abra o arquivo de ontem”. É claro que tal funcionalidade iria demandar um reconhecimento de voz de alta qualidade, que está começando a ficar mais praticável nos computadores atuais. Mas, qualquer que fosse o esquema de acesso, o principal conceito é o de que o usuário pode acessar seus dados sem a necessidade de um conhecimento do nome dos arquivos ou de suas localizações, informações que são atualmente pedidas a ele. O usuário poderia acessar uma dado estritamente através do seu contexto, sem a preocupação sobre o formato do arquivo, a localização do arquivo, ou mesmo em que máquina tal arquivo foi salvo.

3. Projetos de Computação Ubíqua

A seguir três projetos de computação ubíqua serão abordados:

- Projeto Gaia

- Projeto one.world

- Projeto Aura

Isso será feito para, finalmente, completar a abordagem do tema “Frameworks e Middleware para Computação Ubíqua”.



3.1 Projeto Gaia: Infraestrutura para Espaços Ativos


Diversas abordagens têm sido propostas para interação com ambientes de computação ubíqua que são customizados para cenários particulares ou destinados a tipos específicos de aplicação. O projeto Gaia apresenta um sistema operacional genérico para ambientes de computação ubíqua, o qual exporta e coordena os recursos contidos em um espaço físico e, conseqüentemente, facilita o desenvolvimento de aplicações ubíquas. Um ambiente computacional para uma sala física, teatro, edifício, ou cidade, como já discutimos anteriormente, deve ter alguma forma de sistema operacional que organiza o ambiente para simplificar o gerenciamento de recursos, a codificação de aplicações, a identificação e autenticação de usuários, o fornecimento de serviços e a reutilização de software. No projeto Gaia, são definidos um ambiente computacional genérico que converte espaços físicos e seus dipositivos de computação ubíqua em um sistema computacional programável, chamado espaço ativo. Um espaço ativo é análogo aos sistemas de computação tradicionais; basta que um computador seja visto com um objeto, composto por dispositivos de entrada e saída, recursos e periféricos para que componha um espaço ativo.

Sistemas operacionais tradicionais gerenciam as tarefas comuns a todas as aplicações; o mesmo gerenciamento é necessário para espaços físicos. Entretando, ao invés de gerenciar recursos inerentes a um único computador, um sistema operacional para espaços ativos gerencia os recursos computacionais inerentes a um espaço físico.

A pesquisa realizada no projeto Gaia é focada no estudo das questões relacionadas ao design e implementação de um tipo de sistema operacional que facilita o desenvolvimento de aplicações que executam no contexto de um espaço. Nos tópicos que se seguem teremos uma mostra do GaiaOS, um sistema operacional para espaços ativos desenvolvido no projeto, uma descrição do modelo de aplicação que define um framework padrão para a criação de aplicações ubíquas que rodam no contexto de um espaço ativo e uma explicação sobre como coordenar componentes e tarefas no sistema através do uso de uma flexível linguagem de script.

O Gaia tem origem no sistema operacional distribuído 2K (que por sua vez teve origem no Choices, um dos precursores na tentava de criar um SO orientado a objetos baseado na idéia de Exokernel – extrapolação do microkernel - e que foi idealizado à partir do desejo de mostrar que é possível construir um sistema operacional em C++) que deu origem à abordagem de middleware-OS ou meta-OS e que procurou, inicialmente resolver alguns problemas do ambiente distribuído:

- manutenção de múltiplas contas por usuário em ambientes e máquinas diferentes.

Solução: usuário reside na rede (Network-Centric User)

- heterogeneidade do hardware e do software

Solução: implementação como middleware.

- plataformas de middleware existentes no são flexíveis

Solução: middleware reflexivo (dynamicTAO, OpenORB, LuaORB)

- plataformas de middleware são muito pesadas

Solução: ORBs configuráveis muito pequenos (LegORB e UIC CORBA)

- configuração de sistemas é muito penoso e caro

Solução: configuração automática

Muitas dessas características, como vimos e veremos adiante, estão presentes no Gaia.



3.1.1 GaiaOS

GaiaOS é um meta sistema operacional baseado em componentes, ou sistema operacional de middleware, que roda sobre sistemas existentes, como Windows2000, WindowsCE, e Solaris. A infra-estrutura de comunicação utilizada no GaiaOS para integrar as diferentes plataformas é baseada em CORBA. Atualmente, é utilizado o TAO ORB nas estações Unix e nas máquinas Windows, e o UIC ORB nos dispositivos portáteis.

GaiaOS é composto por duas partes principais. No nível mais baixo, o “Unified Object Bus” provê ferramentas para manipular uniformemente componentes heterogêneos que estão executando no sistema. Este “bus” é a base na qual os demais componentes do GaiaOS confiam. O kernel do GaiaOS contém os serviços que implementam o núcleo funcional do sistema, incluindo descoberta de entidades, um repositório de componentes, distribuição de eventos, serviço de nomes, persistência e manipulação de dados e segurança.
3.1.2 Unified Object Bus

Os espaços ativos são altamente heterogêneos por definição, eles são caracterizados por uma grande variedade de dispositivos de hardware e protocolos de software. Entretando, para exportar um espaço como uma entidade programável, tanta heterogeneidade deve ser escondida, “transparente” para quem desenvolve, para quem utiliza o ambiente provido. O “Unified Object Bus” (UOB) é responsável para prover ferramentas comuns para manipular o ciclo de vida dos componentes que estão executando no espaço ativo, sendo responsável pela criação, inspeção, remoção e nomenclatura de tais componentes. O UOB pode manipular diferentes tipos de componentes (CORBA, arquivos de programa nativo e scripts) e provê uma arquitetura aberta para incorporar novos modelos de componentes. (e.g., CORBA, native program files, and scripts)

O UOB define quatro abstrações básicas, o “Unified Component” (ou componente unificado), “Component Manager” (ou gerenciador de componentes), “Component Container” e o UOBHost.

Componentes Unificados são os elementos básicos do UOB. Estes componentes 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.

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

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

Por fim, um UOBHost é qualquer dispositivo capaz de hospedar a execução de componentes. Estes UOBHosts determinam a funcionalidade de criar, remover Component Containers, bem como criar componentes em containers específicos.


3.1.3 Os seviços do kernel

O kernel contém o mínimo dos serviços requeridos para inicializar o GaiaOS em um espaço arbitrário. Um serviço fundamental é o Gerenciador de Eventos, que é utilizado para distribuir informação através dos componentes, mantendo um fraco acoplamento. As aplicações podem registrar canais específicos de eventos a serem notificados com informações ou mudanças no ambiente. Este serviço é utilizado para dar suporte a aplicações sensíveis a contexto no Gaia, ou seja, aplicações que se adaptem ao local no qual estão sendo executadas, bem como às pessoas e objetos e às mudanças destes ao longo do tempo.

O Serviço de Descoberta utiliza o Gerenciador de Eventos para rastrear componentes de software, pessoas e entidades físicas presentes no espaço. Os dispositivos, serviços, aplicações e usuários atualmente ativos no espaço são armazenados no “Repositóro do Espaço”.

O Repositório do Espaço determina uma interface para a busca de entidades específicas baseadas em condições como localização, tipo de serviço e disponibilidade de recursos.

As aplicações acessam os dados através do Serviço de Dados (Data Object Service), um sistema de arquivos dinamicamente tipado que suporta adaptação de conteúdo, acesso customizado aos dados e consciência de localização.

O armazenamento de dados pessoais pode ser feito em máquinas desktop remotas ou em dispositivos móveis de finalidade específica. Um usuário pode definir o armazenamento pessoal que pode ser incorporado em um espaço quando ele está fisicamente presente neste espaço.

Os serviços de seguranças no GaiaOS incluem autenticação, controle de acesso, carga dinâmica segura de componentes, rastreamento seguro e privacidade de localização. GaiaOS emprega um Serviço de Autenticação que utiliza credenciais para verificação de identidade de usuários. Estas credenciais permitem ao Serviço de Controle de Acesso prover um prudente e imperativo controle de acesso baseado em regras, perfis (roles).
3.1.4 O Modelo de Aplicações Gaia

O modelo de aplicações do Gaia provê um framework padrão para construir aplicações para cenários de computação ubíqua e propõe uma nova maneira de utilizar as aplicações, baseada no paradigma de computação ubíqua. Este modelo de aplicações é baseado no paradigma Model-View-Controller (MVC), aumentado com extensões que o adaptam às características dos ambientes de computação ubíqua.


3.1.4.1 MVC Tradicional

MVC define um design modular que modela o comportamento de aplicações interativas que claramento encapsulam o modelo do domínio da aplicação (model), a visualização do modelo (view) e os mecanismos para interação com o modelo (controller). Esta arquitetura modular simplifica a tarefa de modificar e estender aplicações, bem como reutilizar componentes específicos.

Um modelo tem uma ou mais visões relacionadas, que são responsáveis por exibir os dados de algum jeito particular. Um dos principais benefícios desta separação entre model e view é que o mesmo modelo pode ser exibido de maneiras distintas. O modelo explicitamente conhece seus dependentes (views) e é responsável por informar mudanças em seu estado para que os mesmos possam se atualizar. O último elemento requerido é o controlador (controller) que permite aos usuários interagir com o modelo da aplicação através de qualquer uma de suas visões. Um controlador conhece seu respectivo par model-view bem como uma referência a um sensor de entrada que captura os eventos gerados pelos usuários. O resultado de um evento de entrada depende da view associada e as ações derivadas do mecanismo de controle são automaticamente enviadas às views associadas ao modelo.
3.1.4.2 MVC para Espaços Ativos

Os conceitos definidos pelo MVC tradicional são válidos para qualquer aplicação interativa, independentemente da especificidade do ambiente no qual a aplicação executa. Uma aplicação tem um modelo e provê uma representação do mesmo para que os usuários possam percebê-lo e tem mecanismos para modificar o estado do modelo. Entretanto, a maioria das implementações existentes de MVC é personalizada para os ambientes tradicionais das aplicações e conseqüentemente é difícil reutilizar tais implementações no contexto de espaços ativos. No Gaia, foi adotado um modelo de aplicação que mapeia o paradigma MVC para ambientes de espaço ativo. Este novo modelo leva a uma série de questões relacionadas à computação ubíqua: a variedade de dispositivos de interação; as propriedades de contexto associadas ao usuário e o espaço no qual a aplicação executa; a mobilidade da visão, modelo e controlador; aplicações rodando no contexto de um usuário ou espaço e não no contexto de um dispositivo particular. O modelo de aplicação utilizado no Gaia padroniza o modo como são feitos o design, a construção e a montagem das aplicações para espaços ativos. Da perspectiva do usuário, este modelo de aplicação define como utilizar e personalizar aplicações. Estas aplicações executam em um espaço físico habitado por usuários e um usuário interage com o espaço como uma entidade única e não como uma coleção de dispositivos e serviços digitais individuais e dissociados.

O MVC tradicional apresenta o modelo para o usuário através das visões, que são responsáveis por exibir o estado do modelo de alguma forma. Nas aplicações ubíquas, a apresentação do estado do modelo ao usuário não necessariamente implica em exibílo (renderizá-lo). O modelo pode ser apresentado de qualquer maneira que afete os sentidos do usuário, como som, odores e vibrações.

Baseado no modelo de aplicação do Gaia, foi desenvolvido um framework para suportar o desenvolvimento de aplicações ubíquas chamado Model-Presentation-Adapter-Controller-Coordinator (MPACC) – Modelo-Apresentação-Adaptador-Controlador.

Este framework define cinco componentes principais:


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

  2. Presentation – É a externalização física do modelo que permite aos usuários percebê-lo através de um ou mais sentidos.

  3. Adapter – É o componente responsável por adaptar o formato dos dados do modelo às características de um dispositivo de saída. Fazer uma espécie de tradução.

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

  5. 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. O coordenador guarda referências aos componentes que compõem a aplicação, bem como as políticas considerando adaptação, personalização e mobilidade da aplicação.

A figura anterior ilustra o diagrama esquemático do framework de aplicação do Gaia.
3.1.5 Coordenação do Espaço Ativo

Além de seus serviços e do frmework de aplicação, o GaiaOS também apresenta suporte para configuração e coordenação aplicações e componentes do sistema operacional de uma maneira simples. Para prover esse tipo de suporte foi escolhido um mecanismo baseado em linguagens de script de alto nível. Como em outros sistemas operacionais, como Unix com Bourne Shell e MS-Windows com as facilidades do script de host do Windows, a linguagem de script do Gaia é capaz de automatizar o gerenciamento e a configuração de tarefas. Por exemplo, scripts podem coordenar o processo de bootstrap, configurar os serviços do GaiaOS e reconfigurar o sistema para reagir às mudanças de contexto. Entretanto, uma boa linguagem de script pode ser utilizada para diversos fins em um sistema como o GaiaOS, além de servir para realização da coordenação de tarefas e descrição das configurações de serviços. Como o GaiaOS é um sistema operacional baseado em componentes, uma linguagem com um conjunto interessante de abstrações e mecanismos deve ser utilizada para conectar os componentes disponíveis a fim de compor novos serviços e aplicações.

Uma linguagem de script também provê uma alternativa interessante de design para o desenvolvimento de aplicações ubíquas, facilitando o processo de testes, possibilita um rápido processo de prototipação e configuração dinâmica, já que se pode carregar e testar novas alternativas de design para uma aplicação de um modo rápido e simples. Por exemplo, um componente pode ser testado por um conjunto de scripts, enquanto outros componentes que ainda não foram implementados ainda, mas necessários para tal componente, podem ser representados por protótipos implementados com a própria linguagem de script. Componentes implementados com uma linguagem de script podem ser modificados dinamicamente e estendidos sem as fases de compilação e linkagem e ainda assim, sem interromper seus serviços.

Com uma linguagem interpretada é fácil enviar código através de uma rede o que permite ao sistema fazer modificações remotas ou interativas e extensões para componentes e serviços distribuídos.


3.1.6 Lua e LuaOrb

Para prover as facilidades de script, GaiaOS usa a ferramenta de script LuaOrb. LuaOrb é uma ferramenta de programação para sistemas baseados em componentes que provê conexão dinâmica de componentes provenientes de diferentes infra-estruturas como CORBA, COM e Java.

LuaOrb estende a linguagem interpretada Lua com um conjunto de facilidades para prover acesso às infra-estruturas de componentes e pode executar as seguintes tarefas em tempo de execução: (1) a identificação de novos tipos de componentes e a integração de suas instâncias em uma aplicação dinamicamente montada, (2) a implementação de novos componentes utilizando Lua, e (3) a extensão e adaptação de componentes disponíveis também utilizando Lua.

Atualmente LuaOrb implementa mapeamentos entre linguagens como entre Lua e CORBA, COM e Java. Ao invés de utilizar o mecanismo tradicional baseado em stubs gerados estaticamente, o design destes mapeamentos é fortemente baseado nos mecanismos de reflexão providos por Lua e na infra-estrutura de componentes: interface de introspecção, montagem de chamada dinâmica e definição de implementação dinâmica. Os mapeamentos (bindings) de LuaOrb usam um mecanismo chamado Proxy genérico para prover acesso aos componentes disponíveis e usam outro mecanismo chamado adaptador genérico para dar suporte à implementação dinâmica de componentes utilizando Lua. Devido a conexão de proxies genéricos a adaptadores genéricos pode-se criar bridges dinâmicas entre diferentes sistemas de componentes. Utilizando estas bridges dinâmicas, componentes de diferentes sistemas podem interoperar independentemente. Conseqüentemente, Lua age como uma linguagem de “cola”, na qual podemos escrever código em tempo de execução que pode usar e misturar componentes de diferentes sistemas livremente.

Além da interoperabilidade e das facilidades de programação baseada em componentes que LuaOrb provê, o uso de uma linguagem como Lua é muito aplicável para cenários nos quais se quer utilizar o GaiaOS, por causa de seu rápido engine de linguagem com um pequeno rastro de memória e por ser completamente implementada em ANSI C, Lua tem sido utilizada em muitas plataformas, incluindo sistemas embedded e dispositivos de mão. Conseqüentemente, o GaiaOS pode prover facilidades de script até mesmo para dispositivos com recursos limitados.
3.1.7 Integrando LuaOrb com o Gaia

LuaOrb realiza diferentes tarefas no GaiaOS. Inicialmente LuaOrb foi utilizada para testar alguns componentes do Gaia e para implementar protótipos de novos serviços. Entretanto, ela também está sendo utilizada para implementar algumas “features” mais específicas para espaços ativos. As facilidades de descrição de dados da Lua estão sendo utilizadas para prover um mecanismo declarativo (ao invés de um baseado em procedimentos) que especifica um conjunto de componentes que devem ser criados em um espaço ativo. Isso tem sido utilizado para coordenar o bootstrap do GaiaOS, para iniciar os cenários de demonstração, para realizar os testes de aplicação e para implementar os scripts de login para os usuários. Devido ao caráter unificador de LuaOrb, pode-se criar e utilizar nestes scripts declarativos componentes de diferentes sistemas.

LuaOrb também é utilizada para implementar dois importantes tipos de componentes no Gaia. O primeiro é um tipo de componente que pode ser chamado de Context Controller ou Controlador de Contexto. Este tipo de componente captura eventos relacionados às informações de contexto provenientes do Gerenciador de Eventos e dispara ações específicas quando certas condições são satisfeitas. Utilizando tais componentes, tradutores de contexto podem ser facilmente implementados para “ouvir” eventos específicos e traduzi-los, agregá-los ou quebrá-los para gerar novos eventos. O segundo tipo de componentes é o Coordinator ou Coordenador do framework de aplicação. As características de LuaOrb também facilitam a implementação deste tipo de componente que serve de cola para os outros componentes, coordena suas atividades e define as políticas de configuração.

LuaOrb trabalha com o framework de aplicação do Gaia e com o UOB para prover adaptação e composição dinâmica de aplicações ubíquas: enquanto LuaOrb oferece um mecanismo para comandar reconfigurações dinâmicas de conexões de componentes, a infra-estrutura do UOB e o framework MPACC oferecem os meios que permitem a reconfiguração das conexões de componentes (re-wiring).

1   2   3   4


©principo.org 2016
enviar mensagem

    Página principal