Solar: uma proposta de middleware pervasivo

Os sistemas pervasivos funcionam de maneira muito isolada e acabam não tirando vantagem de todos os recursos disponíveis em outros sistemas.

Se os sistemas que utilizam computação onipresente pudessem compartilhar seus recursos (como sensores, infra-estrutura de software e hardware), o custo de cada sistema pervasivo seria muito reduzido.

Diversos ramos da ciência da computação precisam ser unidos e desenvolvidos para que essa infraestrutura comum possa ser oferecida aos sistemas pervasivos.

Neste contexto existem alguns projetos que oferecem propostas de soluções para algum destes problemas. Um destes projetos é o Solar da universidade de Darthmouth que é apresentado neste trabalho:

O Sistema do Projeto Solar é constituído de quatro tipos de elementos: Estrela, Planeta, Aplicação e sensores e operadores.

A estrela é o núcleo do sistema no Solar. Existe apenas uma estrela e as aplicações devem conhecer sua localização lógica. A estrela deve receber das aplicações as especificações dos dados que devem ser fornecidos a elas.

Os planetas tanto recebem da Estrela as informações referentes aos sensores e operadores necessários, tanto podem enviar informações à Estrela, entretanto informações podem ser trocadas também entre planetas não precisando passar essas informações pela Estrela, eles devem ainda fornecer as informações necessárias a Aplicação. Desta forma o Solar busca evitar que a Estrela seja gargalo do sistema.

A aplicação está interessada nas informações que são disponibilizadas pelos sensores e operadores para oferecer determinado serviço.

Os Sensores captam a informação bruta, como temperatura ambiente ou percentual de utilização da CPU de um computador.

Para tratar as informações captadas pelos sensores, existem os operadores. Os operadores modificam as informações dos sensores para que elas se ajustem aos parâmetros fornecidos pela aplicação.

Como exemplo de aplicações do Solar temos:

Doorbell: Esta aplicação consiste em informa a disponibilidade de uma pessoa em uma sala através de uma tela posicionada à porta. Por exemplo: O sistema tem um sensor no modem que informa se o telefone da sala está sendo utilizado ou não. No caso do telefone estar sendo utilizado, o status apresentado na tela é que tem alguém. Ou o sensor ainda informa a presença de pessoas na sala.

iNote: A segunda aplicação Solar é o iNote. Esta aplicação nada mais é do que um bloco de notas. Entretanto não um simples bloco de notas, mas um inteligente. O iNote é acionado quando a quando a presença do professor não é detectada em sua sala. As mensagens são apresentadas na mesma tela da aplicação Doorbell. O sistema ainda fornece informações sobre quem está próximo a interface, o aplicativo pesquisa se existe algum recado destinado àquela pessoa, caso exista, esse recado é apresentado. O usuário pode ainda responder o recado que será devidamente armazenado e apresentado ao destinatário em momento oportuno.

WhiteBoard: O WhiteBoard é uma aplicação que se dedica a armazenar as informações discutidas em determinada reunião.

Sua interface consiste de um quadro onde são anotados os assuntos discutidos na reunião: desenhos, principais tópicos, tarefas pendentes etc.

Espaço de Tuplas

Um espaço de tuplas tem como função criar uma abstração de memória compartilhada sobre um sistema distribuído. Por propiciar modelos de programação muito simples e com baixo acoplamento entre os elementos do sistema, espaços de tuplas têm sido empregados na construção de sistemas distribuídos complexos. O espaço de tuplas JavaSpaces é um dos mais populares espaços de tuplas para a linguagem Java. Ele tem como características relevantes a conformidade a objetos, a persistência e o emprego de transações. As atuais implementações de JavaSpaces apresentam restrições como: complexidade de configuração, limitação de alcance e não serem abertas. Por “complexidade de configuração” entende-se ter que usar boa parte da infra-estrutura Jini (feita para facilitar o desenvolvimento e administração de sistemas distribuídos) e o Remote Method Invocation (mecanismo de chamadas remotas padrão no ambiente Java), mesmo quando eles seriam dispensáveis. Por "limitação de alcance", entende-se não poder usar as implementações sobre redes amplas, como a Internet. Por “não ser aberto” entende-se que: ou o código fonte não está disponível ou o código fonte e o aplicativo são distribuídos por licenças de software proprietárias ou o uso do software requer algum componente proprietário. Um projeto de espaço de tuplas em conformidade com a especificação JavaSpaces e que busca contornar as restrições acima é apresentado neste trabalho. São destaques do projeto proposto: 1. Dispensar o Remote Method Invocation pois utiliza sockets diretamente; 2. Implementar a persistência sobre bases de dados relacionais; 3. Suscitar o emprego de um mecanismo direto para obtenção de proxies Jini. As características 1 e 3 simplificam a configuração do espaço de tuplas e viabilizam o seu emprego da Internet. A característica 2 viabiliza uma implementação baseada em software aberto. Um protótipo foi implementado para verificar as idéias propostas.
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/

Técnicas de Escalabilidade

ESCONDER A LATÊNCIA NA COMUNICAÇÃO:

Contruir a aplicação de forma a utilizar somente comunicação assícrona,
em aplicações batch e paralelas normalmente é bem aceita mas o mesmo não ocorre em aplicações interativas; neste caso, uma solução é diminuir a necessidade de comunicação movendo parte da computação do servidor para cliente.

REPLICAÇÃO:

Aumenta a disponibilidade e ajuda a balancear a carga de trabalho entre componentes
levando a um melhor desenpenho.

Caching é uma forma especial de replicação na qual a decisão de trazer o objeto é de
seu cliente e não de seu proprietário.

Pode levar a ploblemas de consistência.