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.
domingo, 28 de setembro de 2008
Técnicas de Escabilidade
Escalabilidade pode ser definida como a habilidade de garantir a qualidade de serviço desejada à medida que a demanda de uso aumenta. Uma solução pode ser considerada escalável se continuar respondendo dentro de limites estabelecidos apesar de um aumento na sua carga.Para compreender o que e escalabilidade, primeiro e preciso entender a capacidade de um sistema, que pode ser definido como a quantidade de processos, ou usuários, que o sistema consegue suportar e ainda assim manter a qualidade do serviço. Se um sistema esta no máximo de sua capacidade e não consegue responder dentro de um limite estabelecido, podemos afirmar que esse sistema ultrapassou o seu limite de escalabilidade. Para escalar um sistema que atingiu a sua capacidade máxima, será preciso adicionar mais hardware. Esse hardware adicional pode ser adicionado verticalmente ou horizontalmente.E importante lembrar que, ao definir a arquitetura de uma solução, será preciso considerar como o sistema ira se comportar no caso do ambiente precisar ser escalado.
Escalabilidade VerticalE alcançada ao aumentar a capacidade em um hardware, entende-se por capacidade a adição de mais processadores, memória ou discos a maquina atual.Escalar de forma vertical dificilmente ira ter algum impacto na sua arquitetura.Apesar disso, não e possível garantir a disponibilidade da aplicação, uma vez que um único hardware representa um ponto único de falha, conhecido como SPOF (Single Point of Failure).Geralmente a escalabilidade vertical é mais barata e demanda um menor esforço de manutenção que a escalabilidade horizontal.
Escalabilidade HorizontalE possível alcançar a escalabilidade horizontal ao adicionar mais maquinas ao ambiente atual, aumentando assim a capacidade do sistema como um todo.Para distribuir a carga de maneira otimizada para cada servidor , você devera usar as técnicas de balanceamento de carga (Load Balancing) e de montagem de clusters.A arquitetura definida para a aplicação deve ser projetada tendo em mente que ela devera funcionar sem problemas em um ambiente que pode escalar horizontalmente.Ao escalar de forma horizontal você consegue garantir a flexibilidade, disponibilidade e confiabilidade para o ambiente e para a aplicação.Em contra partida você aumenta a complexidade e o gerenciamento da estrutura física da aplicação, alem de ser uma solução mais cara que a escalabilidade vertical.
Escalabilidade DiagonalPara implementar uma solução que seja confiável, resiliente, performática, escalável e de alta disponibilidade, que usa de forma inteligente todo o poder disponibilizado pelo hardware, se faz necessário aplicar em conjunto as técnicas de escalabilidade horizontal e vertical, conhecida como escalabilidade diagonal.
ConclusãoEscalabilidade significa adicionar hardware para manter e melhorar a performance de uma solução.Entretanto, apenas adicionar mais hardware pode não representar ganho de performance por parte da aplicação.Antes de escalar o ambiente, e importante validar se todos os gargalos da aplicação foram devidamente eliminados, se o código esta otimizado e o ambiente devidamente configurado e otimizado.Caso estas boas práticas não sejam executadas, escalar o ambiente apenas vai empurrar o problema mais pra frente. Por outro lado, quando a solução está devidamente otimizada, então escalar o ambiente se torna o próximo passo lógico para uma maior capacidade e performance para a solução.
quarta-feira, 24 de setembro de 2008
Trabalho 1- Orientação a objetos aplicada a computação pervasiva
A computação pervasiva surge como um modelo computacional que visa integrar de forma transparente os vários componentes de hardware e software já existentes com vistas a obter uma gama de potenciais aplicações que facilitam as tarefas dos usuários nestes ambientes. Entretanto o principal obstáculo encontrado no esforço de desenvolver ambientes pervasivos é obter a integração transparente entre as facilidades oferecidas por estes componentes com as necessidades do usuário.
A arquitetura é composta de três camadas: Aplicação, Componentes e Sistema. A camada Aplicação, por sua vez, dispõe ao programador dois níveis de abstração no desenvolvimento de aplicações. Em um nível maior de abstração, o programador apenas declara seus componentes, por meio de classes do paradigma orientado a objetos. Em outro nível, a aplicação é estendida de forma a resolver questões de mobilidade e pervasividade segundo os conhecimentos dos programadores sobre o comportamento da aplicação. O grande desafio na computação pervasiva é integrar de forma transparente os vários componentes de hardware e software existentes. Exemplos de componentes de hardware podem ser encontrados em dispositivos eletrônicos (sensores, eletrodomésticos, entre outros) e componentes móveis computacionais tais como celulares, PDAs e laptops. Já componentes de software em sua maioria constituem-se de aplicações, componentes reutilizáveis e serviços de software. Este trabalho propõe o paradigma de OOP como forma de estruturar e integrar os diferentes componentes de hardware e software existentes. A expectativa é de que, apesar das diferenças entre esses componentes, todos podem ser potencialmente representados por objetos do paradigma de OOP. Conceitualmente, este paradigma viabiliza um mapeamento direto do mundo real para o programa orientado a objetos, sendo, portanto aplicável na tarefa de modelar os diversos componentes de hardware existentes. Os objetos do paradigma possuem capacidade de receber mensagens, de processarem dados e de enviar mensagens a outros objetos, o que caracteriza a interatividade dos objetos correspondentes no mundo real.
Os serviços, por sua vez, não necessariamente são estruturados via paradigma de OOP. Essas construções essencialmente provêem serviços através de uma Interface Description Language (IDL), que define o serviço e seu protocolo de mensagem independente de sua implementação e da plataforma utilizada.
Arquitetura de MagnOb
MagnOb oferece suporte ao desenvolvimento e execução de aplicações pervasivas através de uma arquitetura em camadas, é dividida em três camadas: Aplicação, Componentes e Sistema. Na camada Aplicação, aplicações são desenvolvidas em termos de seus objetos e, opcionalmente, através do uso de facilidades providas por uma API para a manipulação destes objetos. Na camada
Componentes, estes objetos têm sua funcionalidade estendida, de forma transparente às demais camadas, para suportar diversos recursos e mapeamentos previstos no modelo de programação e de execução. A camada
Sistema, por sua vez, é responsável por criar uma arquitetura virtual de suporte à execução dos objetos de MagnOb.
Interface de programação
Para que objetos possam fazer parte do ambiente de execução pervasiva, suas respectivas classes devem ser declaradas com a palavra-reservada mclass (MagnOb class), em substituição a palavra-reservada class de Java. As classes declaradas dessa forma são pré-processadas por uma compilador integrado à ferramenta com vistas a introduzir suporte aos vários recursos oferecidos pelo modelo de programação e execução de MagnOb.
Na camada Aplicação, os recursos introduzidos pelo pré-processamento são acessados através de uma API, a qual consiste em uma interface estendida das classes que definem objetos MagnOb. Nesse contexto, instâncias dessas classes terão acesso a outros métodos além daqueles implementados ou herdados por estas classes. Esta abordagem permite que a vinculação de tipos de dados utilizados para a manipulação de objetos MagnOb seja realizada em tempo de compilação, sendo transparente em tempo de desenvolvimento e gerando menos overhead em tempo de execução.
Link: http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a9.pdf
A arquitetura é composta de três camadas: Aplicação, Componentes e Sistema. A camada Aplicação, por sua vez, dispõe ao programador dois níveis de abstração no desenvolvimento de aplicações. Em um nível maior de abstração, o programador apenas declara seus componentes, por meio de classes do paradigma orientado a objetos. Em outro nível, a aplicação é estendida de forma a resolver questões de mobilidade e pervasividade segundo os conhecimentos dos programadores sobre o comportamento da aplicação. O grande desafio na computação pervasiva é integrar de forma transparente os vários componentes de hardware e software existentes. Exemplos de componentes de hardware podem ser encontrados em dispositivos eletrônicos (sensores, eletrodomésticos, entre outros) e componentes móveis computacionais tais como celulares, PDAs e laptops. Já componentes de software em sua maioria constituem-se de aplicações, componentes reutilizáveis e serviços de software. Este trabalho propõe o paradigma de OOP como forma de estruturar e integrar os diferentes componentes de hardware e software existentes. A expectativa é de que, apesar das diferenças entre esses componentes, todos podem ser potencialmente representados por objetos do paradigma de OOP. Conceitualmente, este paradigma viabiliza um mapeamento direto do mundo real para o programa orientado a objetos, sendo, portanto aplicável na tarefa de modelar os diversos componentes de hardware existentes. Os objetos do paradigma possuem capacidade de receber mensagens, de processarem dados e de enviar mensagens a outros objetos, o que caracteriza a interatividade dos objetos correspondentes no mundo real.
Os serviços, por sua vez, não necessariamente são estruturados via paradigma de OOP. Essas construções essencialmente provêem serviços através de uma Interface Description Language (IDL), que define o serviço e seu protocolo de mensagem independente de sua implementação e da plataforma utilizada.
Arquitetura de MagnOb
MagnOb oferece suporte ao desenvolvimento e execução de aplicações pervasivas através de uma arquitetura em camadas, é dividida em três camadas: Aplicação, Componentes e Sistema. Na camada Aplicação, aplicações são desenvolvidas em termos de seus objetos e, opcionalmente, através do uso de facilidades providas por uma API para a manipulação destes objetos. Na camada
Componentes, estes objetos têm sua funcionalidade estendida, de forma transparente às demais camadas, para suportar diversos recursos e mapeamentos previstos no modelo de programação e de execução. A camada
Sistema, por sua vez, é responsável por criar uma arquitetura virtual de suporte à execução dos objetos de MagnOb.
Interface de programação
Para que objetos possam fazer parte do ambiente de execução pervasiva, suas respectivas classes devem ser declaradas com a palavra-reservada mclass (MagnOb class), em substituição a palavra-reservada class de Java. As classes declaradas dessa forma são pré-processadas por uma compilador integrado à ferramenta com vistas a introduzir suporte aos vários recursos oferecidos pelo modelo de programação e execução de MagnOb.
Na camada Aplicação, os recursos introduzidos pelo pré-processamento são acessados através de uma API, a qual consiste em uma interface estendida das classes que definem objetos MagnOb. Nesse contexto, instâncias dessas classes terão acesso a outros métodos além daqueles implementados ou herdados por estas classes. Esta abordagem permite que a vinculação de tipos de dados utilizados para a manipulação de objetos MagnOb seja realizada em tempo de compilação, sendo transparente em tempo de desenvolvimento e gerando menos overhead em tempo de execução.
Link: http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a9.pdf
terça-feira, 23 de setembro de 2008
Resumo do Trabalho 3 - Uma Proposta de Cenarios e Servi?os de Suporte paraJogos Multiusuario Multiplataforma Pervasivos
1. INTRODUCAO
Jogos multiusuario distribuídos vem se tornando um tópico de pesquisa em grande evidencia. Nestas aplicações, dois ou mais jogadores participam de um mesmo jogo, interagindo cooperativamente ou competitivamente, através de diferentes maquinas. Inicialmente restritos a pequenos grupos de jogadores conectados através de redes locais em maquinas de mesma plataforma, estas aplicações tem sofrido profundas transformações decorrentes das evoluções tecnológicas dos últimos anos. Mais recentemente, o avanço deste cenário criou a idéia dos Jogos Macicamente Multiusuario, do inglês Massively Multiplayer Games (MMG).
Outro cenário que vem despertando interesse e o de jogos em dispositivos moveis, ou móbile games. O crescente mercado de computação móvel de voz e dados, associado ao surgimento de plataformas abertas como J2ME [14] criaram um campo promissor para tais aplicações.
Um conceito ainda mais recente neste sentido e o de jogos pervasivos ou jogos ubíquos. Sistemas de computação pervasiva propõem o acesso de suas aplicações e dados através de diferentes dispositivos, via redes de comunicação sem fio, onde dados contextuais são monitorados pelas aplicações, que modificam seu comportamento em função de mudanças relevantes nestas informações. No caso de jogos pervasivos, informações do contexto do mundo real do jogador, em especial sua localização física, são utilizados como elementos essenciais para a dinamica do jogo.
Em nosso trabalho, estes jogos levarão ainda em conta informações de contexto, como localização física do jogador, para guiar a participação do usuário no jogo.
O acesso ao mundo virtual será irrestrito, criando situações onde jogadores utilizando diferentes dispositivos possam estar lado a lado dentro do mundo virtual, competindo ou cooperando de acordo com os objetivos do jogo. Ao mesmo tempo, nossa visão defende que estes jogos aproveitarão situações especıficas, como a formação de redes espontaneas via dispositivos moveis, objetivando aumentar a imersão do usuário no jogo.
Neste documento, este jogos são denominados Jogos Multiusuario Multiplataforma Pervasivos (PM2G – do ingles, Pervasive Multiplayer Multiplatform Games).
Primeiramente, no que diz respeito aos jogos multiusuario, destacam-se a necessidade de suporte a um alto numero de usuários e o combate ao uso de trapaça por parte de alguns jogadores. Em relação aos aspectos pervasivos, a necessidade de suporte a um diversificado conjunto de dispositivos requer adaptações no modo como jogadores percebem e interagem com o jogo. Em consequencia, esta heterogeneidade impoe a idéia de uma competição justa (do ingles, fairness) entre jogadores, mesmo quando da existencia de diferentes condições de acesso. O uso de dispositivos moveis traz consigo problemas relativos ao alto consumo de bateria em virtude da necessidade de comunicação sem fio com o mundo virtual.
Este trabalho aborda parte destes problemas, principalmente aqueles relacionados com a necessidade de adaptação da jogabilidade em face ao uso de dispositivos heterogeneos.
São apresentados modelos que permitem unificar a visão de conceitos que compõem nossa proposta. A segunda contribuição e de natureza arquitetural, onde apresentados seis serviços que objetivam oferecer suporte ao desenvolvimento e execução destas aplicações. Este artigo esta organizado em seis seções. A segunda seção aponta trabalhos relacionados a proposta PM2G. A terceira seção apresenta cenários elaborados a partir da visão proposta para a integração entre dispositivos moveis, pervasividade e jogos multiusuario. A partir destes cenários, a quarta seção apresenta dois modelos relativos aos conceitos de um jogo PM2G e ao modo de interação entre jogadores e aplicação. Na quinta seção são apresentados os seis serviços de suporte a jogos PM2G. Por fim, a sexta seção apresenta conclusões e trabalhos futuros.
2. TRABALHOS RELACIONADOS
Fox
· A necessidade da adaptação da jogabilidade de jogadores via diferentes dispositivos em um MMG.
· Como cada jogador interage com o mundo virtual.
Han et al
· Proposta de um middleware sensível a situação para jogos multiplataforma.
· Cinco tipos de plataforma são suportadas: consoles, maquinas comerciais (arcade machines, ex: flipperama), computadores pessoais, PDAs e telefones celulares.
· Jogadores em uma plataforma podem migrar o estado de seus jogos entre diferentes plataformas, de acordo com a situa cão do jogador.
· O middleware utiliza informações de sensores que detectam situa coes (como presença de um dispositivo melhor adequado para o jogador), e comportamento associado a cada situação(por exemplo, transferencia do estado entre dispositivos).
Projeto IPerg (EU Integrated Project on Pervasive Games - http://iperg.sics.se/).
Visa o estudo de novas e atrativas formas para implementação de jogos pervasivos. Um de seus subprojetos, batizado de Massive Multiplayer Reaching Out (MMRO), tem como objetivo:
· Desenvolvimento de jogos inovadores que integrem infra-estruturas técnicas de computação móvel.
· Serviços baseados em localização e realidade virtual, com tradicionais MMGs.
· Idéia de dois ambientes ou “espaços” distintos, porem interconectados: um relativo ao mundo real e outro ao mundo virtual.
· Estrutura de um jogo sugere que ações realizadas em diferentes sub-espacos (subconjunto do mundo virtual ou real), tenham influencia simultanea nos demais sub-espacos do jogo.
· Define o estilo chamado de trans-realidade (trans-reality), onde mundo virtual e real são sintetizados em um único ambiente. Como exemplo, o deslocamento do usuário no mundo real representaria o deslocamento de seu avatar no mundo virtual.
3. CENA RIOS PM2G
Infra-estrutura do jogo e formada por um conjunto de servidores que são acessados via Internet, ilustrado na Figura 1. Neste jogo, o principal objetivo de um jogador e a evolução de seu personagem em diferentes critérios, como inteligência, agilidade, experiência ou riquezas materiais. Quando usuário encontra-se em sua casa (Cenário 1), ele joga através de seu computador pessoal que possui acesso banda larga a Internet, com vastos recursos multimídia, permitindo que ele possa participar de batalhas em tempo real altamente interativas com outros jogadores.
Figura 1: Cenários de um Jogo Multiusuario Multiplataforma Pervasivo.
Porem, em certos intervalos de seu dia, Ian não possui estas mesmas condições de acesso ao jogo. Para isto, ele pode utilizar seu telefone celular para acessar o jogo via rede de sua operadora de telefonia, de modo a obter informações sobre seu personagem (Cenario 2) e assim variando seu ambiente, dispositivo e redes disponíveis para acesso.
4. MODELOS PM2G
Modelos propostos:
· Modelo de Aplicação, diz respeito a visão de elementos que compõem o jogo PM2G.
· Modelo de Utilização, ressalta a forma como os usuários interagem com o jogo.
A partir destes modelos, extraímos os requisitos que uma plataforma de suporte necessita oferecer aplicações PM2G.
4.1 Modelo de Aplicação PM2G
O modelo de aplicação PM2G baseia-se nos padrões de jogos de aventura e RPGs (do inglês, Role Playing Game). Nestes jogos, o mundo virtual e representado como uma grande região habitada por dezenas de jogadores, caracterizados por diferentes raças (anões, humanos, elfos) e classes (druidas, guerreiros, paladinos).
Figura 2: Modelo de Aplicação PM2G.
Informações imutáveis que compõem a paisagem do mundo virtual, influenciando o deslocamento dos jogadores como rios, montanhas ou depressões. Em outras palavras, um objeto e qualquer informação que pode ser adicionada, copiada, alterada ou removida do mundo virtual.
No modelo PM2G, estes objetos virtuais também podem ser inseridos em locais do mundo real de cada jogador. Estes objetos representam elementos (armas, porções ou tesouros) que podem ser capturados por um jogador utilizando dispositivos moveis para uso no mundo virtual, através de seu deslocamento aos pontos onde os objetos estejam inseridos virtualmente. Mundo virtual (ou simplesmente mundo) e o sistema de regras ou leis que implementam o espaço virtual onde estão localizados os objetos. Espera-se que o mundo simule um ambiente virtual típico, onde os objetos possuem uma posição relativa aos outros objetos, tamanho, velocidade, aceleração, etc. Espera-se também que quaisquer objetos localizados no mesmo mundo possam interagir entre si (colisão, troca de informações, etc.) e que as interações entre objetos ocorram com maior freqüência quando estes objetos estejam próximos, dentro do mundo virtual. Opcionalmente, um objeto pode ser associado a um jogador, sendo este então considerado o dono deste objeto. E de se esperar que o mundo virtual seja grande e que um jogador, em um dado instante, possa interagir apenas com um subconjunto deste mundo.
Cada jogador tem um estado associado, composto pela posição do jogador no mundo e informações de seu avatar, como habilidades, energia vital e posses.
A idéia de percepção e interação adaptada ao contexto de execução de um jogador permite que o padrão de comportamento entre jogadores que utilizam computadores pessoais e aqueles que utilizem dispositivos moveis seja preservado.
Por fim, o conceito de Mini-mundo esta relacionado com o aproveitamento de novas oportunidades de interação, especıficas para jogadores moveis. Mini-mundos constituiriam-se como cenários paralelos com interação direta entre jogadores via dispositivos moveis, através de redes espontâneas ou redes locais sem fio. Ao contrario do mundo virtual simulado, os mini-mundos são instancias ou partidas de curta duração. Estes cenários podem ser compreendidos como partidas isoladas entre jogadores moveis, porem com consequencias no mundo virtual simulado, de forma semelhante as conseqüências das interações convencionais entre jogadores dentro do mundo virtual.
Ressalva-se que o estabelecimento de mini-mundos poderia ser facilitado através da utilização de serviços de localização.
Estes serviços permitiriam o que jogadores pudessem expor sua localização para demais jogadores, ou ainda procurar por instancias de mini-mundos em andamento nas imediações de sua localização.
Em suma, mini-mundo e caracterizado pela necessária proximidade física (e não apenas virtual) dos usuários - seja na área de abrangência de uma rede local sem fio ou de uma rede espontânea (Ad-hoc).
4.2 Modelo de Utilização
As participações dos jogadores ocorrem através de sessões de interação com o mundo virtual. Uma sessão caracteriza se por um intervalo de tempo em que um jogador interage com o jogo a partir de um dispositivo especıfico, quer seja um computador pessoal ou um dispositivo móvel. Quando encerrada uma sessão, o jogador pode migrar para outro dispositivo, abrindo uma nova sessão e possivelmente continuando as ações a partir do ponto onde a ultima sessão foi finalizada.
5. SERVIÇOS PM2G:
jogos PM2G. O modelo tradicional de suporte a jogos multiusuário utiliza uma camada de serviços na figura de um middleware. Os serviços destes middleware atacam questões comuns ao desenvolvimento de jogos, quer sejam estes massivos, móveis ou pervasivos. Estes serviços estão tipicamente relacionados tanto a requisitos funcionais como gerência de contas, autenticação, tarifação de jogadores, dentre outros, quanto requisitos não-funcionais, como escalabilidade e tolerância a falhas. Tais serviços são tipicamente construídos sobre uma base de serviços de suporte, como os de comunicação e persistência.
5.1 Gerenciamento de Contexto
Toda informação relevante e que caracterize a situação de uma entidade que compõe (software/hardware) ou interage (usuário) com a aplicação e chamada contexto.
O Serviço de Gerenciamento de Contexto tem por finalidade realizar o monitoramento
reativo do contexto de execução de um jogador, para que adaptações necessárias para a participação do jogador possam ser realizadas pelos demais serviços.
O Serviço de Gerenciamento de Contexto tem por finalidade realizar o monitoramento
reativo do contexto de execução de um jogador, para que adaptações necessárias para a participação do jogador possam ser realizadas pelos demais serviços. as informações relevantes para determinar o modo de interação do jogador são: o dispositivo utilizadopara acesso ao jogo, preferências pessoais e a localização física de cada jogador O dispositivo e o elemento principal do contexto, pois indica como a informação do mundo virtual será apresentada ao jogador, quais suas possibilidades de conectividade, dentre outras funcionalidades do middleware.
5.2 Adaptação de Conteúdo:
O fato dos usuários entrarem no jogo com diversas plataformas iferentes, como por exemplo, pcs, palms, celulares, etc. Traz o problema de adaptação de conteúdo, onde independente da plataforma usada, a informação deve ser apresentada da forma correta.
O serviço de adaptação de conteúdo, transforma as ,informações relevantes para um formato adequado ao contexto atual.
5.3 Adaptação de Interação:
As entradas das ações dosjogadores são realisadas de diversas formas diferentes por causa das diversas plataformas usadas. O Serviço de Adaptação de Interação transforma as diferentes formas de entrada dos jogadores em diferentes contextos em ações padronizadas dentro das simulações que formam cada área de interece de jogo.
O Serviço de Adaptação de Interação constitui-se de um gerenciador de adaptação de interação e um conjunto de procedimentos de automação do comportamento dos avata-res de um jogador.
5.4 Notificação de Eventos:
O Serviço de Notificação de Eventos tem a função de informar aos jogadores sobre acontecimentos de seu interesse, quando os jogadores estiverem usando um contexto móvel.
Este serviço e o principal responsável por criar a idéia do jogador móvel estar sempre conectado ao jogo, sendo notificado através de diferentes meios de comunicação, como mensagens SMS ou e-mail.
Este serviço visa criar uma abstração para que jogadores móveis possam ser alertados sobre diferentes eventos relativos tanto de sua área de interesse do mundo virtual, quanto aqueles de seu mundo real.
O ciclo de funcionamento do Serviço de Notificação de Eventos ocorre em momentos distintos. Primeiramente, deve ser permitido ao jogador especificar quais eventos particulares do mundo virtual são de seu interesse.
Em geral, eventos devem ser informados aos jogadores assim que os mesmos tenham acontecido, para que os jogadores possam tomar contramedidas a estes eventos de forma efetiva e em tempo hábil, o que garante a iteratividade do jogo.
5.5 Localização Física:
a localização física de um jogador móvel tem um papel importante na proposta PM2G, como dar suporte a inclusão de objetos virtuais no mundo real ou auxílio na formação dos mini-mundos. O Serviço de Localização Física tem por função rastrear a posição do jogador para que a mesma possa ser utilizada para estes fins.
5.6 Integração de Mini-mundos:
Diz respeito a integração ao jogo dos cenários formados pelo conceito de mini-mundo do modelo de aplicação PM2G. Cada partida paralela iniciada precisa repassar ao jogo informações de seus jogadores, localizações e resultados finais destas partidas.
O estabelecimento do mini-mundo se da de 2 maneiras: A primeira é quando um jogador através de seu dispositivo, cria e acessa um mini-mundo e espera que os adversários entrem nele.
A segunda forma é quando os jogadores participam de um mini-mundo já existente.
6. CONCLUSÕES E TRABALHOS FUTUROSA integração de jogos multiusuários, mobilidade e heterogeneidade de dispositivos apresenta-se como uma tendência para jog.
Thiago
Jogos multiusuario distribuídos vem se tornando um tópico de pesquisa em grande evidencia. Nestas aplicações, dois ou mais jogadores participam de um mesmo jogo, interagindo cooperativamente ou competitivamente, através de diferentes maquinas. Inicialmente restritos a pequenos grupos de jogadores conectados através de redes locais em maquinas de mesma plataforma, estas aplicações tem sofrido profundas transformações decorrentes das evoluções tecnológicas dos últimos anos. Mais recentemente, o avanço deste cenário criou a idéia dos Jogos Macicamente Multiusuario, do inglês Massively Multiplayer Games (MMG).
Outro cenário que vem despertando interesse e o de jogos em dispositivos moveis, ou móbile games. O crescente mercado de computação móvel de voz e dados, associado ao surgimento de plataformas abertas como J2ME [14] criaram um campo promissor para tais aplicações.
Um conceito ainda mais recente neste sentido e o de jogos pervasivos ou jogos ubíquos. Sistemas de computação pervasiva propõem o acesso de suas aplicações e dados através de diferentes dispositivos, via redes de comunicação sem fio, onde dados contextuais são monitorados pelas aplicações, que modificam seu comportamento em função de mudanças relevantes nestas informações. No caso de jogos pervasivos, informações do contexto do mundo real do jogador, em especial sua localização física, são utilizados como elementos essenciais para a dinamica do jogo.
Em nosso trabalho, estes jogos levarão ainda em conta informações de contexto, como localização física do jogador, para guiar a participação do usuário no jogo.
O acesso ao mundo virtual será irrestrito, criando situações onde jogadores utilizando diferentes dispositivos possam estar lado a lado dentro do mundo virtual, competindo ou cooperando de acordo com os objetivos do jogo. Ao mesmo tempo, nossa visão defende que estes jogos aproveitarão situações especıficas, como a formação de redes espontaneas via dispositivos moveis, objetivando aumentar a imersão do usuário no jogo.
Neste documento, este jogos são denominados Jogos Multiusuario Multiplataforma Pervasivos (PM2G – do ingles, Pervasive Multiplayer Multiplatform Games).
Primeiramente, no que diz respeito aos jogos multiusuario, destacam-se a necessidade de suporte a um alto numero de usuários e o combate ao uso de trapaça por parte de alguns jogadores. Em relação aos aspectos pervasivos, a necessidade de suporte a um diversificado conjunto de dispositivos requer adaptações no modo como jogadores percebem e interagem com o jogo. Em consequencia, esta heterogeneidade impoe a idéia de uma competição justa (do ingles, fairness) entre jogadores, mesmo quando da existencia de diferentes condições de acesso. O uso de dispositivos moveis traz consigo problemas relativos ao alto consumo de bateria em virtude da necessidade de comunicação sem fio com o mundo virtual.
Este trabalho aborda parte destes problemas, principalmente aqueles relacionados com a necessidade de adaptação da jogabilidade em face ao uso de dispositivos heterogeneos.
São apresentados modelos que permitem unificar a visão de conceitos que compõem nossa proposta. A segunda contribuição e de natureza arquitetural, onde apresentados seis serviços que objetivam oferecer suporte ao desenvolvimento e execução destas aplicações. Este artigo esta organizado em seis seções. A segunda seção aponta trabalhos relacionados a proposta PM2G. A terceira seção apresenta cenários elaborados a partir da visão proposta para a integração entre dispositivos moveis, pervasividade e jogos multiusuario. A partir destes cenários, a quarta seção apresenta dois modelos relativos aos conceitos de um jogo PM2G e ao modo de interação entre jogadores e aplicação. Na quinta seção são apresentados os seis serviços de suporte a jogos PM2G. Por fim, a sexta seção apresenta conclusões e trabalhos futuros.
2. TRABALHOS RELACIONADOS
Fox
· A necessidade da adaptação da jogabilidade de jogadores via diferentes dispositivos em um MMG.
· Como cada jogador interage com o mundo virtual.
Han et al
· Proposta de um middleware sensível a situação para jogos multiplataforma.
· Cinco tipos de plataforma são suportadas: consoles, maquinas comerciais (arcade machines, ex: flipperama), computadores pessoais, PDAs e telefones celulares.
· Jogadores em uma plataforma podem migrar o estado de seus jogos entre diferentes plataformas, de acordo com a situa cão do jogador.
· O middleware utiliza informações de sensores que detectam situa coes (como presença de um dispositivo melhor adequado para o jogador), e comportamento associado a cada situação(por exemplo, transferencia do estado entre dispositivos).
Projeto IPerg (EU Integrated Project on Pervasive Games - http://iperg.sics.se/).
Visa o estudo de novas e atrativas formas para implementação de jogos pervasivos. Um de seus subprojetos, batizado de Massive Multiplayer Reaching Out (MMRO), tem como objetivo:
· Desenvolvimento de jogos inovadores que integrem infra-estruturas técnicas de computação móvel.
· Serviços baseados em localização e realidade virtual, com tradicionais MMGs.
· Idéia de dois ambientes ou “espaços” distintos, porem interconectados: um relativo ao mundo real e outro ao mundo virtual.
· Estrutura de um jogo sugere que ações realizadas em diferentes sub-espacos (subconjunto do mundo virtual ou real), tenham influencia simultanea nos demais sub-espacos do jogo.
· Define o estilo chamado de trans-realidade (trans-reality), onde mundo virtual e real são sintetizados em um único ambiente. Como exemplo, o deslocamento do usuário no mundo real representaria o deslocamento de seu avatar no mundo virtual.
3. CENA RIOS PM2G
Infra-estrutura do jogo e formada por um conjunto de servidores que são acessados via Internet, ilustrado na Figura 1. Neste jogo, o principal objetivo de um jogador e a evolução de seu personagem em diferentes critérios, como inteligência, agilidade, experiência ou riquezas materiais. Quando usuário encontra-se em sua casa (Cenário 1), ele joga através de seu computador pessoal que possui acesso banda larga a Internet, com vastos recursos multimídia, permitindo que ele possa participar de batalhas em tempo real altamente interativas com outros jogadores.
Figura 1: Cenários de um Jogo Multiusuario Multiplataforma Pervasivo.
Porem, em certos intervalos de seu dia, Ian não possui estas mesmas condições de acesso ao jogo. Para isto, ele pode utilizar seu telefone celular para acessar o jogo via rede de sua operadora de telefonia, de modo a obter informações sobre seu personagem (Cenario 2) e assim variando seu ambiente, dispositivo e redes disponíveis para acesso.
4. MODELOS PM2G
Modelos propostos:
· Modelo de Aplicação, diz respeito a visão de elementos que compõem o jogo PM2G.
· Modelo de Utilização, ressalta a forma como os usuários interagem com o jogo.
A partir destes modelos, extraímos os requisitos que uma plataforma de suporte necessita oferecer aplicações PM2G.
4.1 Modelo de Aplicação PM2G
O modelo de aplicação PM2G baseia-se nos padrões de jogos de aventura e RPGs (do inglês, Role Playing Game). Nestes jogos, o mundo virtual e representado como uma grande região habitada por dezenas de jogadores, caracterizados por diferentes raças (anões, humanos, elfos) e classes (druidas, guerreiros, paladinos).
Figura 2: Modelo de Aplicação PM2G.
Informações imutáveis que compõem a paisagem do mundo virtual, influenciando o deslocamento dos jogadores como rios, montanhas ou depressões. Em outras palavras, um objeto e qualquer informação que pode ser adicionada, copiada, alterada ou removida do mundo virtual.
No modelo PM2G, estes objetos virtuais também podem ser inseridos em locais do mundo real de cada jogador. Estes objetos representam elementos (armas, porções ou tesouros) que podem ser capturados por um jogador utilizando dispositivos moveis para uso no mundo virtual, através de seu deslocamento aos pontos onde os objetos estejam inseridos virtualmente. Mundo virtual (ou simplesmente mundo) e o sistema de regras ou leis que implementam o espaço virtual onde estão localizados os objetos. Espera-se que o mundo simule um ambiente virtual típico, onde os objetos possuem uma posição relativa aos outros objetos, tamanho, velocidade, aceleração, etc. Espera-se também que quaisquer objetos localizados no mesmo mundo possam interagir entre si (colisão, troca de informações, etc.) e que as interações entre objetos ocorram com maior freqüência quando estes objetos estejam próximos, dentro do mundo virtual. Opcionalmente, um objeto pode ser associado a um jogador, sendo este então considerado o dono deste objeto. E de se esperar que o mundo virtual seja grande e que um jogador, em um dado instante, possa interagir apenas com um subconjunto deste mundo.
Cada jogador tem um estado associado, composto pela posição do jogador no mundo e informações de seu avatar, como habilidades, energia vital e posses.
A idéia de percepção e interação adaptada ao contexto de execução de um jogador permite que o padrão de comportamento entre jogadores que utilizam computadores pessoais e aqueles que utilizem dispositivos moveis seja preservado.
Por fim, o conceito de Mini-mundo esta relacionado com o aproveitamento de novas oportunidades de interação, especıficas para jogadores moveis. Mini-mundos constituiriam-se como cenários paralelos com interação direta entre jogadores via dispositivos moveis, através de redes espontâneas ou redes locais sem fio. Ao contrario do mundo virtual simulado, os mini-mundos são instancias ou partidas de curta duração. Estes cenários podem ser compreendidos como partidas isoladas entre jogadores moveis, porem com consequencias no mundo virtual simulado, de forma semelhante as conseqüências das interações convencionais entre jogadores dentro do mundo virtual.
Ressalva-se que o estabelecimento de mini-mundos poderia ser facilitado através da utilização de serviços de localização.
Estes serviços permitiriam o que jogadores pudessem expor sua localização para demais jogadores, ou ainda procurar por instancias de mini-mundos em andamento nas imediações de sua localização.
Em suma, mini-mundo e caracterizado pela necessária proximidade física (e não apenas virtual) dos usuários - seja na área de abrangência de uma rede local sem fio ou de uma rede espontânea (Ad-hoc).
4.2 Modelo de Utilização
As participações dos jogadores ocorrem através de sessões de interação com o mundo virtual. Uma sessão caracteriza se por um intervalo de tempo em que um jogador interage com o jogo a partir de um dispositivo especıfico, quer seja um computador pessoal ou um dispositivo móvel. Quando encerrada uma sessão, o jogador pode migrar para outro dispositivo, abrindo uma nova sessão e possivelmente continuando as ações a partir do ponto onde a ultima sessão foi finalizada.
5. SERVIÇOS PM2G:
jogos PM2G. O modelo tradicional de suporte a jogos multiusuário utiliza uma camada de serviços na figura de um middleware. Os serviços destes middleware atacam questões comuns ao desenvolvimento de jogos, quer sejam estes massivos, móveis ou pervasivos. Estes serviços estão tipicamente relacionados tanto a requisitos funcionais como gerência de contas, autenticação, tarifação de jogadores, dentre outros, quanto requisitos não-funcionais, como escalabilidade e tolerância a falhas. Tais serviços são tipicamente construídos sobre uma base de serviços de suporte, como os de comunicação e persistência.
5.1 Gerenciamento de Contexto
Toda informação relevante e que caracterize a situação de uma entidade que compõe (software/hardware) ou interage (usuário) com a aplicação e chamada contexto.
O Serviço de Gerenciamento de Contexto tem por finalidade realizar o monitoramento
reativo do contexto de execução de um jogador, para que adaptações necessárias para a participação do jogador possam ser realizadas pelos demais serviços.
O Serviço de Gerenciamento de Contexto tem por finalidade realizar o monitoramento
reativo do contexto de execução de um jogador, para que adaptações necessárias para a participação do jogador possam ser realizadas pelos demais serviços. as informações relevantes para determinar o modo de interação do jogador são: o dispositivo utilizadopara acesso ao jogo, preferências pessoais e a localização física de cada jogador O dispositivo e o elemento principal do contexto, pois indica como a informação do mundo virtual será apresentada ao jogador, quais suas possibilidades de conectividade, dentre outras funcionalidades do middleware.
5.2 Adaptação de Conteúdo:
O fato dos usuários entrarem no jogo com diversas plataformas iferentes, como por exemplo, pcs, palms, celulares, etc. Traz o problema de adaptação de conteúdo, onde independente da plataforma usada, a informação deve ser apresentada da forma correta.
O serviço de adaptação de conteúdo, transforma as ,informações relevantes para um formato adequado ao contexto atual.
5.3 Adaptação de Interação:
As entradas das ações dosjogadores são realisadas de diversas formas diferentes por causa das diversas plataformas usadas. O Serviço de Adaptação de Interação transforma as diferentes formas de entrada dos jogadores em diferentes contextos em ações padronizadas dentro das simulações que formam cada área de interece de jogo.
O Serviço de Adaptação de Interação constitui-se de um gerenciador de adaptação de interação e um conjunto de procedimentos de automação do comportamento dos avata-res de um jogador.
5.4 Notificação de Eventos:
O Serviço de Notificação de Eventos tem a função de informar aos jogadores sobre acontecimentos de seu interesse, quando os jogadores estiverem usando um contexto móvel.
Este serviço e o principal responsável por criar a idéia do jogador móvel estar sempre conectado ao jogo, sendo notificado através de diferentes meios de comunicação, como mensagens SMS ou e-mail.
Este serviço visa criar uma abstração para que jogadores móveis possam ser alertados sobre diferentes eventos relativos tanto de sua área de interesse do mundo virtual, quanto aqueles de seu mundo real.
O ciclo de funcionamento do Serviço de Notificação de Eventos ocorre em momentos distintos. Primeiramente, deve ser permitido ao jogador especificar quais eventos particulares do mundo virtual são de seu interesse.
Em geral, eventos devem ser informados aos jogadores assim que os mesmos tenham acontecido, para que os jogadores possam tomar contramedidas a estes eventos de forma efetiva e em tempo hábil, o que garante a iteratividade do jogo.
5.5 Localização Física:
a localização física de um jogador móvel tem um papel importante na proposta PM2G, como dar suporte a inclusão de objetos virtuais no mundo real ou auxílio na formação dos mini-mundos. O Serviço de Localização Física tem por função rastrear a posição do jogador para que a mesma possa ser utilizada para estes fins.
5.6 Integração de Mini-mundos:
Diz respeito a integração ao jogo dos cenários formados pelo conceito de mini-mundo do modelo de aplicação PM2G. Cada partida paralela iniciada precisa repassar ao jogo informações de seus jogadores, localizações e resultados finais destas partidas.
O estabelecimento do mini-mundo se da de 2 maneiras: A primeira é quando um jogador através de seu dispositivo, cria e acessa um mini-mundo e espera que os adversários entrem nele.
A segunda forma é quando os jogadores participam de um mini-mundo já existente.
6. CONCLUSÕES E TRABALHOS FUTUROSA integração de jogos multiusuários, mobilidade e heterogeneidade de dispositivos apresenta-se como uma tendência para jog.
Thiago
Marcos
sábado, 20 de setembro de 2008
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
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.
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.
quinta-feira, 18 de setembro de 2008
Em Direção a um Modelo para Desenvolvimento de Sistemas Computacionais de Qualidade para Aplicações Onivalentes
Resumo:
Sistemas computacionais estão cada vez mais intrusivos nas nossas vidas. Inicialmente restritos a grandes instituições, as pessoas tinham contato somente com as listagens decorrentes das execuções dos programas em grandes máquinas. Na medida em que seus componentes foram se tornando mais baratos e com maior velocidade, novos sistemas computacionais foram surgindo e nossa dependência a eles foi aumentando acentuadamente, tornando – se altamente distribuídos, compostos de inúmeros componentes autônomos que se comunicam através de sinais e protocolos. Neste cenário, há diversos problemas relativos a falhas tanto de software quanto de hardware, segurança, confiabilidade do sistema como um todo, configuração dinâmica e componentes heterogêneos de inúmeros fabricantes (muitos sem especificação conhecida ou comportamento previsível). para o futuro, prevê-se uma realidade onde processadores estarão ainda mais integrados ao cotidiano de maneira quase transparente, idealmente nos informando, nos apoiando e nos protegendo ou, no pior cenário, nos enganando e prejudicando. Pretende-se analisar e identificar interdependências entre os requisitos de dependabilidade, correção, segurança, escalabilidade e evolutividade para garantir a qualidade dos sistemas computacionais do futuro, que estarão presentes no cotidiano. Pretende-se também esboçar idéias de como tratar essas relações e conflitos de forma integrada já nas fases iniciais do projeto do sistema e apresentar os desafios que precisam ser vencidos para a construção de sistemas distribuídos autônomos escaláveis. Seguramente a solução para o tratamento adequado desses requisitos passa por um esforço de reunificação das várias especialidades da computação, aproveitando de cada área sua experiência, suas tentativas mal sucedidas e suas soluções promissoras. Uma dessas soluções seria o uso de Sistemas onivalentes, que na visão de futuro da comunidade de Informática, estarão presentes em todos os ambientes e atividades humanas prestando serviços essenciais para a saúde, educação, informação, comunicação, produção e entretenimento preservando a integridade do ambiente social,
tecnológico e natural. Tais sistemas têm por características distribuição, dinamicidade e ubiqüidade, sendo essas de difícil escalabilidade, que imporão severas dificuldades ao desenvolvimento destes futuros sistemas. Para atender as expectativas e as dificuldades de qualidade de seus inúmeros usuários, precisam garantir da melhor forma possível requisitos de correção, dependabilidade, segurança, escalabilidade e evolutividade.A Interdependência entre os diferentes requisitos serão a chave para a construção das aplicações que dominarão a sociedade futura. Os modelos e abstrações hoje utilizados deverão ser substituídos por outros onde a integração de soluções prevaleça sobre a otimização de um único parâmetro.
FONTE: XXVII Congresso da SBC - XXXIV Seminário Integrado de Software e Hardware
Link: http://www.sbc.org.br/bibliotecadigital/download.php?paper=682
quarta-feira, 17 de setembro de 2008
Sistemas Pervasivos / Pâncreas Artificial
A importância da determinação da glicose no sangue decorre da doença crônica diabete. Aproximadamente 5% da população mundial sofre de diversos tipos dessa doença metabólica. As pessoas que sofrem de diabete tipo I precisam injetar doses diárias do hormônio insulina para equilibrar o valor de glicose no sangue dentro da faixa normal.
O "pâncreas artificial" serve para distribuir aos diabéticos a insulina, hormônio que regula o nível de açúcar no sangue. O aparelho libera insulina na corrente sanguínea quando um sensor detecta aumento nos níveis de açúcar (glicose) no sangue. Normalmente, o pâncreas produz insulina, mas em pessoas com diabete tipo 1, o órgão não consegue fabricar o hormônio. Por esse motivo, esses pacientes precisam tomar injeções de insulina com freqüência para manter a taxa de açúcar sob controle. O equipamento é um reservatório de insulina, que é implantado no tecido que reveste a cavidade abdominal e se conecta a um sensor introduzido na veia jugular. Quando o sensor detecta aumento na taxa de glicose sanguínea, o reservatório libera a quantidade necessária de insulina. O aparelho precisa receber em um determinado tempo uma recarga do hormônio.
Com a utilização do aparelho os níveis de açúcar no sangue permanecem sob controle durante mais de 60 por cento do tempo. Os pacientes que injetam insulina conseguem controlar a taxa de glicose em 25 por cento do tempo. Esse resultado é decorrente da precisão do sensor. O sensor consegue a leitura contínua da taxa de glicose no sangue por fazer centenas de medições durante um período de 24 horas.
Sensores contínuos de glicose
O método de diagnóstico da glicose é através da medição da taxa de glicose sangüínea do paciente. Essa medida é feita através de um exame laboratorial de sangue. Dispositivos portáteis de teste foram desenvolvidos nas últimas décadas. Esses dispositivos requerem uma quantidade ínfima de sangue e retornam uma leitura em poucos minutos. Os sensores de obtém leituras de glicemia várias vezes ao dia, o paciente pode aplicar doses de insulina adequadas a cada situação. Assim, a criação de sensores portáteis de glicose representou um avanço importante no tratamento da diabetes. Para a criação de um pâncreas artificial, o sensor tradicional de glicose não é suficiente. Um sistema de pâncreas artificial necessita de leituras contínuas de glicose. Atualmente foram lançados no mercado alguns sensores contínuos de glicose. Devido à importância do monitoramento da glicose, um grande número de princípios de sensor foi desenvolvido. Apesar de muitas tentativas e abordagens diferentes, o monitoramento contínuo da glicose no sangue mostrou ser um desafio extraordinário.
Bombas de Insulina
Bombas de insulina são dispositivas que injetam insulina no corpo do paciente a uma taxa aproximadamente constante. Há basicamente dois tipos de bomba de insulina: externa e interna. A bomba de insulina externa é o tipo mais comum. É geralmente composta de uma unidade de controle, semelhante a um Pager, e uma agulha para a injeção de insulina. Essa agulha é subcutânea, feita em geral de um material flexível, e liga-se à unidade de controle através de um tubo. A unidade de controle contém uma bateria, um reservatório de insulina, além de um visor de cristal líquido e botões para a interação com o usuário.
Conectividade
O paradigma da computação ubíqua e pervasiva vem sendo viabilizados pelo desenvolvimento das tecnologias móveis, costumam a ser caracterizados por seu pequeno tamanho, alimentação por bateria, por sua mobilidade e por terem uma conexão sem fio. A comunicação sem fio torna nosso cotidiano cada dia mais permeado por aparelhos de informação e tecnologias como laptops, PDAs e celulares.
O pâncreas artificial idealmente teria interfaces para comunicação com dispositivos externos, tanto para fins de aferição de medidas quanto para funções de controle e ajustes. Com o objetivo principal de estabelecer um padrão de conectividade e troca de mensagens que permita a interoperabilidade dos diversos dispositivos de diferentes fabricantes e o estabelecimento de um framework para o desenvolvimento de dispositivos, estações de trabalho, interfaces e aplicações, atualmente existem várias iniciativas neste sentido, das quais se destaca o Health Level Seven (HL7). É um padrão para a troca, gerenciamento e integração de dados que suportam o cuidado clínico do paciente e o gerenciamento, entrega e avaliação de serviços de saúde.
Portanto, é previsível que tanto as iniciativas atuais, como os sensores de glicose e as bombas de insulina, quanto os futuros protótipos de pâncreas artificiais procurem ter seu desenvolvimento de acordo com padrões e protocolos que estão sendo estabelecidos para o contexto de conectividade em dispositivos de testes no local de cuidado.
Fonte: http://alexandre.sabbatini.com/documentos/pancreas-artificial.pdf
O "pâncreas artificial" serve para distribuir aos diabéticos a insulina, hormônio que regula o nível de açúcar no sangue. O aparelho libera insulina na corrente sanguínea quando um sensor detecta aumento nos níveis de açúcar (glicose) no sangue. Normalmente, o pâncreas produz insulina, mas em pessoas com diabete tipo 1, o órgão não consegue fabricar o hormônio. Por esse motivo, esses pacientes precisam tomar injeções de insulina com freqüência para manter a taxa de açúcar sob controle. O equipamento é um reservatório de insulina, que é implantado no tecido que reveste a cavidade abdominal e se conecta a um sensor introduzido na veia jugular. Quando o sensor detecta aumento na taxa de glicose sanguínea, o reservatório libera a quantidade necessária de insulina. O aparelho precisa receber em um determinado tempo uma recarga do hormônio.
Com a utilização do aparelho os níveis de açúcar no sangue permanecem sob controle durante mais de 60 por cento do tempo. Os pacientes que injetam insulina conseguem controlar a taxa de glicose em 25 por cento do tempo. Esse resultado é decorrente da precisão do sensor. O sensor consegue a leitura contínua da taxa de glicose no sangue por fazer centenas de medições durante um período de 24 horas.
Sensores contínuos de glicose
O método de diagnóstico da glicose é através da medição da taxa de glicose sangüínea do paciente. Essa medida é feita através de um exame laboratorial de sangue. Dispositivos portáteis de teste foram desenvolvidos nas últimas décadas. Esses dispositivos requerem uma quantidade ínfima de sangue e retornam uma leitura em poucos minutos. Os sensores de obtém leituras de glicemia várias vezes ao dia, o paciente pode aplicar doses de insulina adequadas a cada situação. Assim, a criação de sensores portáteis de glicose representou um avanço importante no tratamento da diabetes. Para a criação de um pâncreas artificial, o sensor tradicional de glicose não é suficiente. Um sistema de pâncreas artificial necessita de leituras contínuas de glicose. Atualmente foram lançados no mercado alguns sensores contínuos de glicose. Devido à importância do monitoramento da glicose, um grande número de princípios de sensor foi desenvolvido. Apesar de muitas tentativas e abordagens diferentes, o monitoramento contínuo da glicose no sangue mostrou ser um desafio extraordinário.
Bombas de Insulina
Bombas de insulina são dispositivas que injetam insulina no corpo do paciente a uma taxa aproximadamente constante. Há basicamente dois tipos de bomba de insulina: externa e interna. A bomba de insulina externa é o tipo mais comum. É geralmente composta de uma unidade de controle, semelhante a um Pager, e uma agulha para a injeção de insulina. Essa agulha é subcutânea, feita em geral de um material flexível, e liga-se à unidade de controle através de um tubo. A unidade de controle contém uma bateria, um reservatório de insulina, além de um visor de cristal líquido e botões para a interação com o usuário.
Conectividade
O paradigma da computação ubíqua e pervasiva vem sendo viabilizados pelo desenvolvimento das tecnologias móveis, costumam a ser caracterizados por seu pequeno tamanho, alimentação por bateria, por sua mobilidade e por terem uma conexão sem fio. A comunicação sem fio torna nosso cotidiano cada dia mais permeado por aparelhos de informação e tecnologias como laptops, PDAs e celulares.
O pâncreas artificial idealmente teria interfaces para comunicação com dispositivos externos, tanto para fins de aferição de medidas quanto para funções de controle e ajustes. Com o objetivo principal de estabelecer um padrão de conectividade e troca de mensagens que permita a interoperabilidade dos diversos dispositivos de diferentes fabricantes e o estabelecimento de um framework para o desenvolvimento de dispositivos, estações de trabalho, interfaces e aplicações, atualmente existem várias iniciativas neste sentido, das quais se destaca o Health Level Seven (HL7). É um padrão para a troca, gerenciamento e integração de dados que suportam o cuidado clínico do paciente e o gerenciamento, entrega e avaliação de serviços de saúde.
Portanto, é previsível que tanto as iniciativas atuais, como os sensores de glicose e as bombas de insulina, quanto os futuros protótipos de pâncreas artificiais procurem ter seu desenvolvimento de acordo com padrões e protocolos que estão sendo estabelecidos para o contexto de conectividade em dispositivos de testes no local de cuidado.
Fonte: http://alexandre.sabbatini.com/documentos/pancreas-artificial.pdf
sexta-feira, 12 de setembro de 2008
Escalabilidade
Escalabilidade Permitir que o sistema cresça sem grande perda de desempenho Dimensões de crescimento Tamanho: quantidade de usuários e recursos Geografia: acesso a distâncias maiores
Problemas de escalabilidade Centralização de serviços ou dados Um único servidor é responsável por prover um tipo de serviço ou dados Quando o sistema cresce, o servidor não suporta a carga de trabalho
Técnicas de escalabilidade Distribuição: Distribuir entre vários computadores os serviços e os dados,nenhum servidor prestará todos os serviços nem possuirá todos os dados.Se um servidor falhar, nem tudo está perdido.Não é fácil definir um método de distribuição Replicação.Vários servidores com os mesmos serviços e/ou dados,aumenta disponibilidade e desempenho do sistema. Problema Consistência: nem sempre é fácil tratá-la da maneira adequada ou necessária
Problemas de escalabilidade Centralização de serviços ou dados Um único servidor é responsável por prover um tipo de serviço ou dados Quando o sistema cresce, o servidor não suporta a carga de trabalho
Técnicas de escalabilidade Distribuição: Distribuir entre vários computadores os serviços e os dados,nenhum servidor prestará todos os serviços nem possuirá todos os dados.Se um servidor falhar, nem tudo está perdido.Não é fácil definir um método de distribuição Replicação.Vários servidores com os mesmos serviços e/ou dados,aumenta disponibilidade e desempenho do sistema. Problema Consistência: nem sempre é fácil tratá-la da maneira adequada ou necessária
Espaços de Tuplas
Um blackboard pode ser visto como uma área de memória compartilhada que pode ser acessada por diferentes agentes. Os agentes são capazes de escrever, ler e apagar dados desta área, que pode então ser utilizada como uma interface de comunicação entre pos agentes. Além da comunicação explícita entre os agentes um blackboard pode ser utilizado para armazenar informações relativas ao ambiente onde o agente executa. O blackboard pode ser utilizado ainda como área de armazenamento de código e estado de agentes persistentes.
Existem implementações específicas de blackboards denominadas espaços de tuplas à la Linda, também denominados blackboards associativos ou simplesmente espaços de tuplas. Existem dois elementos básicos em um espaço de tuplas: as Tuplas e o próprio Espaço. Ao contrário de mensagens tradicionais, uma tupla é um objeto propriamente dito, composta de uma série de outros objetos. O espaço funciona como um repositório de tuplas e nele podem ser executadas diferentes operações como, por exemplo, leitura e escrita de tuplas.
Tuplas são lidas de um espaço através da utilização de buscas associativas onde coringas2 podem ser utilizados. Por exemplo, a tupla (“mensagem” , “agente1” , “Olá!”) pode ser lida através de uma busca utilizando padrão (“mensagem” , “agente1”, String), onde o String representa um coringa para qualquer conjunto de caracteres.
Espaços de tuplas devem no mínimo implementar as operações básicas de leitura, escrita e retirada de tuplas, mas dependendo da implementação outras operações derivadas destas podem existir, como por exemplo, leitura de um conjunto de tuplas ou o bloqueio do agente que deseja ler uma tupla que ainda não se encontra espaço.
Ao contrário da troca de mensagens tradicional entre agentes, a utilização de espaços de tuplas oferece um estilo de programação desacoplado. Isto pode ser dito porque uma vez que um agente cria e escreve uma tupla em um espaço ele não precisa saber especificamente qual outro agente a lerá nem em que momento isto irá acontecer [9]. Na verdade a existência de uma tupla em um espaço é independente do agente que a criou e dos agentes que possam vir a realizar alguma operação sobre ela.
Existem diversas implementações comerciais de espaços de tuplas. Dentre estas as duas mais conhecidas são IBM TSpaces [35] e Java Spaces [14]. Estas implementações oferecem suporte para as operações básicas de espaços de tuplas (leitura, escrita e retirada de tuplas), além de outras derivadas destas. Também é disponibilizado o controle de transações no acesso aos espaços, e a opção de manter espaços persistentes. Os espaços utilizados nestas implementações também podem ser acessados a partir de clientes remotos.
www2.dbd.puc-rio.br/pergamum/tesesabertas/0115636_02_cap_02.pdf
Um blackboard pode ser visto como uma área de memória compartilhada que pode ser acessada por diferentes agentes. Os agentes são capazes de escrever, ler e apagar dados desta área, que pode então ser utilizada como uma interface de comunicação entre pos agentes. Além da comunicação explícita entre os agentes um blackboard pode ser utilizado para armazenar informações relativas ao ambiente onde o agente executa. O blackboard pode ser utilizado ainda como área de armazenamento de código e estado de agentes persistentes.
Existem implementações específicas de blackboards denominadas espaços de tuplas à la Linda, também denominados blackboards associativos ou simplesmente espaços de tuplas. Existem dois elementos básicos em um espaço de tuplas: as Tuplas e o próprio Espaço. Ao contrário de mensagens tradicionais, uma tupla é um objeto propriamente dito, composta de uma série de outros objetos. O espaço funciona como um repositório de tuplas e nele podem ser executadas diferentes operações como, por exemplo, leitura e escrita de tuplas.
Tuplas são lidas de um espaço através da utilização de buscas associativas onde coringas2 podem ser utilizados. Por exemplo, a tupla (“mensagem” , “agente1” , “Olá!”) pode ser lida através de uma busca utilizando padrão (“mensagem” , “agente1”, String), onde o String representa um coringa para qualquer conjunto de caracteres.
Espaços de tuplas devem no mínimo implementar as operações básicas de leitura, escrita e retirada de tuplas, mas dependendo da implementação outras operações derivadas destas podem existir, como por exemplo, leitura de um conjunto de tuplas ou o bloqueio do agente que deseja ler uma tupla que ainda não se encontra espaço.
Ao contrário da troca de mensagens tradicional entre agentes, a utilização de espaços de tuplas oferece um estilo de programação desacoplado. Isto pode ser dito porque uma vez que um agente cria e escreve uma tupla em um espaço ele não precisa saber especificamente qual outro agente a lerá nem em que momento isto irá acontecer [9]. Na verdade a existência de uma tupla em um espaço é independente do agente que a criou e dos agentes que possam vir a realizar alguma operação sobre ela.
Existem diversas implementações comerciais de espaços de tuplas. Dentre estas as duas mais conhecidas são IBM TSpaces [35] e Java Spaces [14]. Estas implementações oferecem suporte para as operações básicas de espaços de tuplas (leitura, escrita e retirada de tuplas), além de outras derivadas destas. Também é disponibilizado o controle de transações no acesso aos espaços, e a opção de manter espaços persistentes. Os espaços utilizados nestas implementações também podem ser acessados a partir de clientes remotos.
www2.dbd.puc-rio.br/pergamum/tesesabertas/0115636_02_cap_02.pdf
Escalabilidade
Capacidade de todo sistema de manipular uma porção crescente de trabalho de forma uniforme ou estar preparado para o crescimento do mesmo.
Técnicas de escalabilidade
Distribuição
Distribuir entre vários computadores os serviços e os dados
Nenhum servidor prestará todos os serviços nem possuirá todos os dados
Se um servidor falhar, nem tudo está perdido
Não é fácil definir um método de distribuição
Replicação
Vários servidores com os mesmos serviços e/ou dados
Aumenta disponibilidade e desempenho do sistema
Problema
Consistência: nem sempre é fácil tratá-la da maneira adequada ou necessária
Caching
Permitir processos clientes acessar cópias locais
www.eraldoluis.pro.br/downloads/disciplinas/2008.1.ngr/aula06.pdf
Capacidade de todo sistema de manipular uma porção crescente de trabalho de forma uniforme ou estar preparado para o crescimento do mesmo.
Técnicas de escalabilidade
Distribuição
Distribuir entre vários computadores os serviços e os dados
Nenhum servidor prestará todos os serviços nem possuirá todos os dados
Se um servidor falhar, nem tudo está perdido
Não é fácil definir um método de distribuição
Replicação
Vários servidores com os mesmos serviços e/ou dados
Aumenta disponibilidade e desempenho do sistema
Problema
Consistência: nem sempre é fácil tratá-la da maneira adequada ou necessária
Caching
Permitir processos clientes acessar cópias locais
www.eraldoluis.pro.br/downloads/disciplinas/2008.1.ngr/aula06.pdf
SISTEMAS PERVASIVOS
Consciência do contexto do aprendiz em um ambiente de educação pervasiva
Nos sistemas pervasivos, os equipamentos costumam a ser caracterizados por seu pequeno tamanho, pela alimentação por bateria, por sua mobilidade e por terem somente uma conexão sem fio, se bem que nem todas essas características se aplicam a todos dispositivos.
Segundo Ogata 2003, o conhecimento está presente no dia – a – dia em diferentes formas e locais. A essência da educação pervasiva consiste em perceber este conhecimento e relacionar os processos educacionais com o contexto do aprendiz, levando em consideração seu modelo de mobilidade. Alguns novos elementos computacionais para suporte à educação em ambientes pervasivos são necessários, tais como:
Mobilidade: os sistemas educacionais devem dar suporte à mobilidade do aprendiz e o acesso aos recursos educacionais. Esses devem estar disponíveis em vários formatos, distribuídos em uma rede educacional, e não mais localizados em um único local;
Adaptação: a mobilidade e a capacidade do aprendiz de acesso aos recursos educacionais utilizando diferentes recursos computacionais trazem a necessidade de adaptação a estes recursos. Os objetivos, preferências, modelos de aprendizagem, de mobilidade e de contexto do aprendiz devem ser considerados;
Consciência do contexto: a mobilidade do aprendiz traz a possibilidade do mesmo aprender em diferentes cenários e situações, onde diferentes recursos e oportunidades de aprender podem estar disponíveis. É importante pró – ativamente sugerir e indicar ao aprendiz elementos presentes no contexto virtual e não-virtual e que são de interesse dele. Com isto, as informações sobre o local onde se encontra o aprendiz (por exemplo, um evento que está ocorrendo ou vai ocorrer) podem ser relacionadas com seus objetivos educacionais (o aprendiz pode estar interessado no tópico do evento).
O GlobalEdu (Barbosa, 2005), (Barbosa, 2006) é uma infra-estrutura para suporte aos processos de ensino e aprendizagem em um cenário pervasivo de acesso em larga escala.
No GlobalEdu, contexto é definido como toda informação relevante para o aprendiz e que pode ser obtida para suporte ao seu processo educacional, levando em consideração seu modelo.
O Contexto Social do aprendiz refere-se as informações sobre uma determinada localização. Essa pode ser a localização de uma Região geográfica ou de uma Sub região. Assim, o Contexto Social descreve características associadas a Pessoas, Eventos e Recursos da localização onde se encontra o aprendiz. As informações de Contexto Social são armazenadas em um Repositório de Contexto Social.
O Contexto Físico manipula informações de interesse da execução do A3P e dos recursos educacionais acessados pelo aprendiz, quais sejam: tipo e banda da rede que o aprendiz está acessando dentro do contexto, sua localização, o tipo e autonomia do dispositivo em uso no momento. Além dessas informações, é percebida a presença de outros A3Ps no contexto. Essa informação identifica outros aprendizes com os mesmos objetivos, competências e preferências que o aprendiz na mesma localização. Assim, o A3P tem a capacidade de relacionar aprendizes dentro de um mesmo contexto.
A estratégia de adaptação ao contexto permite ao SE Gerência de Contexto do GlobalEdu relacionar as informações do modelo do aprendiz com o contexto. Havendo restrições dos elementos de contexto físico (como um dispositivo com recursos limitado), o serviço orienta o processo educacional levando em consideração as preferências do aprendiz. Sempre que a localização é alterada, o serviço adapta e sugere ao aprendiz acesso às informações de Contexto Social que são relevantes para ele.
O MeetAgent consiste em uma versão simplificada do A3P. Tem como objetivo permitir a interação entre aprendizes que tenham interesses e objetivos em comum e que estão presentes em um mesmo contexto. Assim, foram implementadas funcionalidades do sistema que permitem a identificação e o relacionamento de aprendizes no contexto, sendo a identificação responsabilidade do SE Modelo de Aprendiz e o relacionamento do SE Gerência de Contexto.
A aplicação MeetAgent relaciona aprendizes em um mesmo contexto, auxiliando a identificar afinidades entre eles, permitindo assim um processo de interação mútua. O modelo de consciência do contexto proposto foi validado com dois aprendizes no âmbito de um campus universitário.
http://www.cinted.ufrgs.br/renote/jul2006/artigosrenote/a41_21219.pdf
Nos sistemas pervasivos, os equipamentos costumam a ser caracterizados por seu pequeno tamanho, pela alimentação por bateria, por sua mobilidade e por terem somente uma conexão sem fio, se bem que nem todas essas características se aplicam a todos dispositivos.
Segundo Ogata 2003, o conhecimento está presente no dia – a – dia em diferentes formas e locais. A essência da educação pervasiva consiste em perceber este conhecimento e relacionar os processos educacionais com o contexto do aprendiz, levando em consideração seu modelo de mobilidade. Alguns novos elementos computacionais para suporte à educação em ambientes pervasivos são necessários, tais como:
Mobilidade: os sistemas educacionais devem dar suporte à mobilidade do aprendiz e o acesso aos recursos educacionais. Esses devem estar disponíveis em vários formatos, distribuídos em uma rede educacional, e não mais localizados em um único local;
Adaptação: a mobilidade e a capacidade do aprendiz de acesso aos recursos educacionais utilizando diferentes recursos computacionais trazem a necessidade de adaptação a estes recursos. Os objetivos, preferências, modelos de aprendizagem, de mobilidade e de contexto do aprendiz devem ser considerados;
Consciência do contexto: a mobilidade do aprendiz traz a possibilidade do mesmo aprender em diferentes cenários e situações, onde diferentes recursos e oportunidades de aprender podem estar disponíveis. É importante pró – ativamente sugerir e indicar ao aprendiz elementos presentes no contexto virtual e não-virtual e que são de interesse dele. Com isto, as informações sobre o local onde se encontra o aprendiz (por exemplo, um evento que está ocorrendo ou vai ocorrer) podem ser relacionadas com seus objetivos educacionais (o aprendiz pode estar interessado no tópico do evento).
O GlobalEdu (Barbosa, 2005), (Barbosa, 2006) é uma infra-estrutura para suporte aos processos de ensino e aprendizagem em um cenário pervasivo de acesso em larga escala.
No GlobalEdu, contexto é definido como toda informação relevante para o aprendiz e que pode ser obtida para suporte ao seu processo educacional, levando em consideração seu modelo.
O Contexto Social do aprendiz refere-se as informações sobre uma determinada localização. Essa pode ser a localização de uma Região geográfica ou de uma Sub região. Assim, o Contexto Social descreve características associadas a Pessoas, Eventos e Recursos da localização onde se encontra o aprendiz. As informações de Contexto Social são armazenadas em um Repositório de Contexto Social.
O Contexto Físico manipula informações de interesse da execução do A3P e dos recursos educacionais acessados pelo aprendiz, quais sejam: tipo e banda da rede que o aprendiz está acessando dentro do contexto, sua localização, o tipo e autonomia do dispositivo em uso no momento. Além dessas informações, é percebida a presença de outros A3Ps no contexto. Essa informação identifica outros aprendizes com os mesmos objetivos, competências e preferências que o aprendiz na mesma localização. Assim, o A3P tem a capacidade de relacionar aprendizes dentro de um mesmo contexto.
A estratégia de adaptação ao contexto permite ao SE Gerência de Contexto do GlobalEdu relacionar as informações do modelo do aprendiz com o contexto. Havendo restrições dos elementos de contexto físico (como um dispositivo com recursos limitado), o serviço orienta o processo educacional levando em consideração as preferências do aprendiz. Sempre que a localização é alterada, o serviço adapta e sugere ao aprendiz acesso às informações de Contexto Social que são relevantes para ele.
O MeetAgent consiste em uma versão simplificada do A3P. Tem como objetivo permitir a interação entre aprendizes que tenham interesses e objetivos em comum e que estão presentes em um mesmo contexto. Assim, foram implementadas funcionalidades do sistema que permitem a identificação e o relacionamento de aprendizes no contexto, sendo a identificação responsabilidade do SE Modelo de Aprendiz e o relacionamento do SE Gerência de Contexto.
A aplicação MeetAgent relaciona aprendizes em um mesmo contexto, auxiliando a identificar afinidades entre eles, permitindo assim um processo de interação mútua. O modelo de consciência do contexto proposto foi validado com dois aprendizes no âmbito de um campus universitário.
http://www.cinted.ufrgs.br/renote/jul2006/artigosrenote/a41_21219.pdf
TÉCNICAS DE ESCALABILIDADE
Há discussões sobre alguns problemas da escalabilidade, problemas que podem ser geralmente solucionados. Porque os problemas nos sistemas distribuídos aparecem como problemas de desempenho causado por capacidade limitada de servidores e rede, há basicamente, três técnicas de escalabilidade: latência de comunicação, distribuição e replicação.
Latência de comunicação: é aplicada no caso da escalabilidade geográfica. Constrói a aplicação de forma a utilizar somente comunicação assíncrona, 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 o cliente.
Distribuição: um componente é dividido em partes menores, distribuindo essas partes no sistema. Um bom exemplo de distribuição é a “Internet Domain Name System (DNS)”. O DNS é hierarquicamente, organizado em uma árvore de domínios, que são divididos entre zonas.
Replicação: a replicação não somente aumenta a disponibilidade, mas também ajuda a equilibrar a carga entre componentes, o que resulta em melhor desempenho. Em sistemas de ampla dispersão geográfica, ter uma copia por perto pode ocultar grande parte dos problemas de latência de comunicação.
Latência de comunicação: é aplicada no caso da escalabilidade geográfica. Constrói a aplicação de forma a utilizar somente comunicação assíncrona, 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 o cliente.
Distribuição: um componente é dividido em partes menores, distribuindo essas partes no sistema. Um bom exemplo de distribuição é a “Internet Domain Name System (DNS)”. O DNS é hierarquicamente, organizado em uma árvore de domínios, que são divididos entre zonas.
Replicação: a replicação não somente aumenta a disponibilidade, mas também ajuda a equilibrar a carga entre componentes, o que resulta em melhor desempenho. Em sistemas de ampla dispersão geográfica, ter uma copia por perto pode ocultar grande parte dos problemas de latência de comunicação.
http://www1.fatecsp.br/aguiar/sistemasdistribuidos.htm
Espaço de Tuplas
Existem dois elementos básicos em um espaço de tuplas: As Tuplas e o próprio Espaço. Ao contrário de mensagens tradicionais, uma tupla é um objeto propriamente dito, composta de uma série de outros objetos.
O espaço funciona como um repositório de tuplas e nele podem ser executadas diferentes operações como, por exemplo, leitura e escrita de tuplas.
Tuplas são lidas de um espaço através da utilização de buscas associativas onde coringas podem ser utilizados. Por exemplo, a tupla ("mensagem" , "agente1" , "Olá!"), pode ser lida através de uma busca utilizando padrão ("mensagem" , "agente1" , String), onde o String representa um coringa para qualquer conjunto de caracteres.
Espaços de tuplas devem no mínimo implementar as operações básicas de leitura, escrita e retirada de tuplas, mas dependendo da implementação outras operações derivadas destas podem existir, como por exemplo, leitura de um conjunto de tuplas ou o bloqueio do agente que deseja ler uma tupla que ainda não se encontra espaço.
Ao contrário da troca de mensagens tradicional entre agentes, a utilização de espaços de tuplas oferece um estilo de programação desacoplado. Isto pode ser dito porque uma vez que um agente cria e escreve uma tupla em um espaço ele não precisa saber especificamente qual outro agente a lerá nem em que momento isto irá acontecer. Na verdade a existência de uma tupla em um espaço é independente do agente que a criou e dos agentes que possam vir a realizar alguma operação sobre ela.
Existem diversas implementações comerciais de espaços de tuplas. Dentre estas as duas mais conhecidas são IBM TSpaces [35] e Java Spaces [14]. Estas implementações oferecem suporte para as operações básicas de espaços de tuplas (leitura, escrita e retirada de tuplas), além de outras derivadas destas. Também é disponibilizado o controle de transações no acesso aos espaços, e a opção de manter espaços persistentes.
Os espaços utilizados nestas implementações também podem ser acessados a partir de clientes remotos.
Link : http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0115636_02_cap_02.pdf
O espaço funciona como um repositório de tuplas e nele podem ser executadas diferentes operações como, por exemplo, leitura e escrita de tuplas.
Tuplas são lidas de um espaço através da utilização de buscas associativas onde coringas podem ser utilizados. Por exemplo, a tupla ("mensagem" , "agente1" , "Olá!"), pode ser lida através de uma busca utilizando padrão ("mensagem" , "agente1" , String), onde o String representa um coringa para qualquer conjunto de caracteres.
Espaços de tuplas devem no mínimo implementar as operações básicas de leitura, escrita e retirada de tuplas, mas dependendo da implementação outras operações derivadas destas podem existir, como por exemplo, leitura de um conjunto de tuplas ou o bloqueio do agente que deseja ler uma tupla que ainda não se encontra espaço.
Ao contrário da troca de mensagens tradicional entre agentes, a utilização de espaços de tuplas oferece um estilo de programação desacoplado. Isto pode ser dito porque uma vez que um agente cria e escreve uma tupla em um espaço ele não precisa saber especificamente qual outro agente a lerá nem em que momento isto irá acontecer. Na verdade a existência de uma tupla em um espaço é independente do agente que a criou e dos agentes que possam vir a realizar alguma operação sobre ela.
Existem diversas implementações comerciais de espaços de tuplas. Dentre estas as duas mais conhecidas são IBM TSpaces [35] e Java Spaces [14]. Estas implementações oferecem suporte para as operações básicas de espaços de tuplas (leitura, escrita e retirada de tuplas), além de outras derivadas destas. Também é disponibilizado o controle de transações no acesso aos espaços, e a opção de manter espaços persistentes.
Os espaços utilizados nestas implementações também podem ser acessados a partir de clientes remotos.
Link : http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0115636_02_cap_02.pdf
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.
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/
Técnicas de Escalabilidade
O desempenho do sistema não deve ser degradado na medida que o número de nós cresce.
Um sistema distribuído que opera bem com 10 máquinas também deve funcionar bem com 10.000 máquinas.
Escalabilidade pode ser definida em 3 níveis:
Tamanho : Facilidade de adicionar usuários e recursos.
Termos Geográficos: Usuários e recursos estão podem estar geograficamente distribuídos.
Termos Administrativos: Facilidade de gerenciar, mesmo com várias áreas administrativas.
Link do trabalho: http://ftpredesesistemas.fatern.edu.br/isaniolopes/Requisitos%20de%20Software%20para%20Sistemas%20Distribu%C3%ADdos.pdf
Um sistema distribuído que opera bem com 10 máquinas também deve funcionar bem com 10.000 máquinas.
Escalabilidade pode ser definida em 3 níveis:
Tamanho : Facilidade de adicionar usuários e recursos.
Termos Geográficos: Usuários e recursos estão podem estar geograficamente distribuídos.
Termos Administrativos: Facilidade de gerenciar, mesmo com várias áreas administrativas.
Link do trabalho: http://ftpredesesistemas.fatern.edu.br/isaniolopes/Requisitos%20de%20Software%20para%20Sistemas%20Distribu%C3%ADdos.pdf
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/
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/
Espaço de Tuplas
Modelo de Memória com operações de escrita e leitura.
Sistemas distribuídos tem no espaço de tuplas uma memória comum onde todos podem ler e escrever no mesmo.
O espaço de tuplas cria uma "ilusão" de que existe um espaço compartilhado entre os objetos no sistema disttribuido, mas na realidade os objetos estão dispostos nas memórias dos nós de cada sistema distribuido.
Um espaço de tuplas é dito com segurança de funcionamento se ele provê os atributos
de segurança de funcionamento. Os atributos relevantes neste caso são: Confiabilidade:
as operações realizadas no espaço de tuplas fazem com que seu estado se modifique de acordo com sua especificação;
Disponibilidade: o espaço de tuplas sempre está pronto para executar as perações requisitadas por partes autorizadas;
Integridade: nenhuma alteração imprópria no estado de um espaço de tuplas pode ocorrer, i.e. o estado de um espaço de tuplas só pode ser alterado através da execução das operações suportadas por ele;
Confidencialidade: o conteúdo de (alguns) campos de uma tupla não podem ser
revelados a partes não autorizadas.
A dificuldade em garantir estes atributos advém da ocorrência de faltas, de natureza
acidental (um bug no software ou uma parada no servidor) ou maliciosa(um invasor que modifica uma tupla no servidor).
O objetivo é evitar que estas faltas causem uma falha no espaço de tuplas, i.e. que um ou mais destes atributos sejam violados. Deste modo, é garantido que o espaço de tuplas se comportará de acordo com sua especificação, mesmo na presença de alguns servidores faltosos.
link:
http://homepages.di.fc.ul.pt/~mpc/pubs/confidencialidade.pdf
Sistemas distribuídos tem no espaço de tuplas uma memória comum onde todos podem ler e escrever no mesmo.
O espaço de tuplas cria uma "ilusão" de que existe um espaço compartilhado entre os objetos no sistema disttribuido, mas na realidade os objetos estão dispostos nas memórias dos nós de cada sistema distribuido.
Um espaço de tuplas é dito com segurança de funcionamento se ele provê os atributos
de segurança de funcionamento. Os atributos relevantes neste caso são: Confiabilidade:
as operações realizadas no espaço de tuplas fazem com que seu estado se modifique de acordo com sua especificação;
Disponibilidade: o espaço de tuplas sempre está pronto para executar as perações requisitadas por partes autorizadas;
Integridade: nenhuma alteração imprópria no estado de um espaço de tuplas pode ocorrer, i.e. o estado de um espaço de tuplas só pode ser alterado através da execução das operações suportadas por ele;
Confidencialidade: o conteúdo de (alguns) campos de uma tupla não podem ser
revelados a partes não autorizadas.
A dificuldade em garantir estes atributos advém da ocorrência de faltas, de natureza
acidental (um bug no software ou uma parada no servidor) ou maliciosa(um invasor que modifica uma tupla no servidor).
O objetivo é evitar que estas faltas causem uma falha no espaço de tuplas, i.e. que um ou mais destes atributos sejam violados. Deste modo, é garantido que o espaço de tuplas se comportará de acordo com sua especificação, mesmo na presença de alguns servidores faltosos.
link:
http://homepages.di.fc.ul.pt/~mpc/pubs/confidencialidade.pdf
Técnicas de Escalabilidade - Sistemas Distribuidos
Escalabilidade
Escalabilidade é uma característica em todo o sistema, onde sua função é manipular uma porção crescente de trabalho de forma uniforme ou estar preparado para o crescimento do mesmo.
Técnicas de Escalabilidade
Existem técnicas de escalabilidade onde a aplicação pode ajudar a esconder a Latência da Comunicação, construindo uma aplicação de forma a utilizar somente comunicação assíncrona.
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 o cliente.
Outra técnica muito usada é a Distribuição, onde é realizado uma divisão do espaço de nomes DNS em Zonas. Podendo assim vários clientes realizar uma comunicação em paralelo.
Uma outra técnica muito usada é a Replicação, com ela podemos aumentar a disponibilidade e ajudar a balancear a carga de trabalho entre componentes, mas com isso pode ocorrer problemas de inconsistência.
link:
http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/caracterizacao.pdf
http://pt.wikipedia.org/wiki/Escalabilidade
Escalabilidade é uma característica em todo o sistema, onde sua função é manipular uma porção crescente de trabalho de forma uniforme ou estar preparado para o crescimento do mesmo.
Técnicas de Escalabilidade
Existem técnicas de escalabilidade onde a aplicação pode ajudar a esconder a Latência da Comunicação, construindo uma aplicação de forma a utilizar somente comunicação assíncrona.
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 o cliente.
Outra técnica muito usada é a Distribuição, onde é realizado uma divisão do espaço de nomes DNS em Zonas. Podendo assim vários clientes realizar uma comunicação em paralelo.
Uma outra técnica muito usada é a Replicação, com ela podemos aumentar a disponibilidade e ajudar a balancear a carga de trabalho entre componentes, mas com isso pode ocorrer problemas de inconsistência.
link:
http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/caracterizacao.pdf
http://pt.wikipedia.org/wiki/Escalabilidade
|| Escabilidade - Sistemas Distribuidos ||
Escalabilidade
A escalabilidade pode ser medida em três dimensões:
1. em relação ao tamanho – pode-se acrescentar mais
utilizadores e recursos ao sistema;
2. em relação à distância geográfica – os componentes
podem estar distantes geograficamente;
3. em relação à facilidade de administração – o sistema
continua gerível mesmo incluindo muitas organizações
independentes.
Problemas de escalabilidade
1. em relação ao tamanho
Servidores centralizados
Dados centralizados
Algoritmos centralizados
1.1 Uma máquina tem informação completa sobre
o estado do sistema, ou
1.2 As máquinas tomam decisões baseadas em
informações de outros nós, ou
1.3 Uma falha de um nó pode arruinar o
algoritmo, ou
1.4 Assume-se que existe um relógio global.
Mas por vezes é inevitável ter centralização (dados
confidenciais de bancos, etc.) …
2. em relação à distância geográfica
Em LANs é comum usar comunicação síncrona – o cliente
envia o pedido e fica bloqueado à espera de uma resposta.
Numa WAN:
a comunicação pode durar três ordens de grandeza
mais (centenas de milisegundos);
a comunicação é pouco fiável – tem de se lidar com
erros.
Não se pode usar técnicas de difusão para localizar serviços – é necessário recorrer a serviços de directórios ou de nomes.
Se uma aplicação tem componentes centralizados fica também
limitada em termos geográficos.
3. em relação à facilidade de administração
Problemas de conciliação de políticas de utilização e
pagamento de recursos, administração e segurança.
São necessários dois tipos de medidas de segurança quando o
sistema distribuído se expande para um novo domínio:
o sistema tem de se proteger de ataques vindos do novo
domínio;
o domínio tem de se proteger de ataques vindos do
sistema distribuído.
Técnicas de certificação e de controlo de acessos.
Técnicas de escalabilidade
Três técnicas principais:
1. Esconder latência na comunicação
2. Distribuição
3. Replicação.
1. Esconder latência na comunicação
Usar comunicação assíncrona para evitar bloquear processos à
espera de receber respostas.
a) Tratamento de respostas como eventos;
b) Usar várias tarefas em paralelo para continuar
processamento.
Passar parte do processamento do servidor para o cliente.
2. Distribuição
Decompor os componentes em partes mais pequenas, que são
distribuídas por todo o sistema distribuído.
Exemplos: DNS e Web
Vários clientes podem aceder a diferentes partes em paralelo.
3. Replicação
Aumenta a disponibilidade dos serviços e melhora o
balanceamento de carga no sistema.
Aumenta a disponibilidade do serviço nas zonas da rede onde
há réplicas.
link: http://tele1.dee.fct.unl.pt/rit2_2007_2008/teo/4_sist_dist.pdf
A escalabilidade pode ser medida em três dimensões:
1. em relação ao tamanho – pode-se acrescentar mais
utilizadores e recursos ao sistema;
2. em relação à distância geográfica – os componentes
podem estar distantes geograficamente;
3. em relação à facilidade de administração – o sistema
continua gerível mesmo incluindo muitas organizações
independentes.
Problemas de escalabilidade
1. em relação ao tamanho
Servidores centralizados
Dados centralizados
Algoritmos centralizados
1.1 Uma máquina tem informação completa sobre
o estado do sistema, ou
1.2 As máquinas tomam decisões baseadas em
informações de outros nós, ou
1.3 Uma falha de um nó pode arruinar o
algoritmo, ou
1.4 Assume-se que existe um relógio global.
Mas por vezes é inevitável ter centralização (dados
confidenciais de bancos, etc.) …
2. em relação à distância geográfica
Em LANs é comum usar comunicação síncrona – o cliente
envia o pedido e fica bloqueado à espera de uma resposta.
Numa WAN:
a comunicação pode durar três ordens de grandeza
mais (centenas de milisegundos);
a comunicação é pouco fiável – tem de se lidar com
erros.
Não se pode usar técnicas de difusão para localizar serviços – é necessário recorrer a serviços de directórios ou de nomes.
Se uma aplicação tem componentes centralizados fica também
limitada em termos geográficos.
3. em relação à facilidade de administração
Problemas de conciliação de políticas de utilização e
pagamento de recursos, administração e segurança.
São necessários dois tipos de medidas de segurança quando o
sistema distribuído se expande para um novo domínio:
o sistema tem de se proteger de ataques vindos do novo
domínio;
o domínio tem de se proteger de ataques vindos do
sistema distribuído.
Técnicas de certificação e de controlo de acessos.
Técnicas de escalabilidade
Três técnicas principais:
1. Esconder latência na comunicação
2. Distribuição
3. Replicação.
1. Esconder latência na comunicação
Usar comunicação assíncrona para evitar bloquear processos à
espera de receber respostas.
a) Tratamento de respostas como eventos;
b) Usar várias tarefas em paralelo para continuar
processamento.
Passar parte do processamento do servidor para o cliente.
2. Distribuição
Decompor os componentes em partes mais pequenas, que são
distribuídas por todo o sistema distribuído.
Exemplos: DNS e Web
Vários clientes podem aceder a diferentes partes em paralelo.
3. Replicação
Aumenta a disponibilidade dos serviços e melhora o
balanceamento de carga no sistema.
Aumenta a disponibilidade do serviço nas zonas da rede onde
há réplicas.
link: http://tele1.dee.fct.unl.pt/rit2_2007_2008/teo/4_sist_dist.pdf
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.
Linda é um espaço de tuplas constituído de um conjunto de seis operações e um sistema de run-time( que é composto por daemons em execução nos diversos nós do sistema).
As operações de Linda são usadas ao longo do código-fonte de um programa que se quer executar e que é escrito em alguma linguagem de programação associada ao Linda( mais comumente C ou Fortran). Um pré-compilador transforma as operações de Linda em instruções de mais baixo nível dirigidas para o sistema run-time. Essas instruções são escritas na linguagem associada e são inseridas diretamente no código-fonte. Durante a execução do programa o sistema de run-time responde às requisições devidamente construídas pelo pré-processador.
O pré-compilador Linda possui, a priori, informações sobre os componentes, as características e a configuração do sistema distribuído sobre o qual o programa será executado. Desta forma, o pré-compilador pode otimizar alguns parâmetros de execução do sistema run-time, como, por exemplo, a distribuição das tuplas. Portanto, Linda é um espaço de tuplas voltado para sistemas distribuídos fechados.
Linda é um espaço de tuplas constituído de um conjunto de seis operações e um sistema de run-time( que é composto por daemons em execução nos diversos nós do sistema).
As operações de Linda são usadas ao longo do código-fonte de um programa que se quer executar e que é escrito em alguma linguagem de programação associada ao Linda( mais comumente C ou Fortran). Um pré-compilador transforma as operações de Linda em instruções de mais baixo nível dirigidas para o sistema run-time. Essas instruções são escritas na linguagem associada e são inseridas diretamente no código-fonte. Durante a execução do programa o sistema de run-time responde às requisições devidamente construídas pelo pré-processador.
O pré-compilador Linda possui, a priori, informações sobre os componentes, as características e a configuração do sistema distribuído sobre o qual o programa será executado. Desta forma, o pré-compilador pode otimizar alguns parâmetros de execução do sistema run-time, como, por exemplo, a distribuição das tuplas. Portanto, Linda é um espaço de tuplas voltado para sistemas distribuídos fechados.
sexta-feira, 5 de setembro de 2008
Trabalho de Sistemas Pervasivos
Cada grupo deve resumir o artigo escolhido e publicar o resumo no blog. Os alunos embarcados devem entrar em contato comigo até segunda de preferecia em izalmo@ucam-campos.br para que possa passar um trabalho diferenciado.
1 - Orientação a objetos aplicada a computação pervasiva
http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a9.pdf
Grupo: Everton, Felipe, Edilson
2 - Em Direção a um Modelo para Desenvolvimento de Sistemas
Computacionais de Qualidade para Aplicac¸ ˜oes Onivalentes
www.sbc.org.br/bibliotecadigital/download.php?paper=682
Grupo: Bruno, Maycon, Miguel
3 - Uma Proposta de Cenarios e Servi?os de Suporte paraJogos Multiusuario Multiplataforma Pervasivos
http://www.cin.ufpe.br/~famt/docs/cientific_production/webmedia2006_enxuto.pdf
Grupo: Thiago, Marcos
4 - Consciência do contexto do aprendiz em umambiente de educação pervasiva
http://www.cinted.ufrgs.br/renote/jul2006/artigosrenote/a41_21219.pdf
Grupo: Caio, Marcio
5 - Solar: uma proposta de middleware pervasivo
https://saloon.inf.ufrgs.br/twiki/viewfile/Disciplinas/Old/CMP167/TF041DartMouthSolar?rev=1.1;filename=TF041DartMouthSolar.doc
Grupo: Cassius, Ivonei, Clébio
1 - Orientação a objetos aplicada a computação pervasiva
http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a9.pdf
Grupo: Everton, Felipe, Edilson
2 - Em Direção a um Modelo para Desenvolvimento de Sistemas
Computacionais de Qualidade para Aplicac¸ ˜oes Onivalentes
www.sbc.org.br/bibliotecadigital/download.php?paper=682
Grupo: Bruno, Maycon, Miguel
3 - Uma Proposta de Cenarios e Servi?os de Suporte paraJogos Multiusuario Multiplataforma Pervasivos
http://www.cin.ufpe.br/~famt/docs/cientific_production/webmedia2006_enxuto.pdf
Grupo: Thiago, Marcos
4 - Consciência do contexto do aprendiz em umambiente de educação pervasiva
http://www.cinted.ufrgs.br/renote/jul2006/artigosrenote/a41_21219.pdf
Grupo: Caio, Marcio
5 - Solar: uma proposta de middleware pervasivo
https://saloon.inf.ufrgs.br/twiki/viewfile/Disciplinas/Old/CMP167/TF041DartMouthSolar?rev=1.1;filename=TF041DartMouthSolar.doc
Grupo: Cassius, Ivonei, Clébio
Espaço de Tuplas (conceito e implementações: JavaSpaces, Linda e Lime)
CONCEITO
Um espaço de tuplas tem como função criar uma abstração de memória compartilhada sobre um sistema distribuído, onde todos podem ler e escrever no mesmo. Porém, na realidade os objetos estão dispostos nas memórias dos nós de cada sistema distribuído.
IMPLEMENTAÇÕES
• JavaSpaces
O espaço de tuplas JavaSpaces é um dos mais populares espaços de tuplas para a linguagem Java. As instruções abaixo descrevem como criar programas que compartilhem memória utilizando o JavaSpaces. Será utilizada a implementação do JavaSpaces do JINI e uma classe auxiliar para conectar ao serviço JavaSpace.
Código:
// Definindo o Formato das Mensagens
import net.jini.core.entry.Entry;
public class Message implements Entry {
public String content;
public Message() { } }
// Escrevendo no Espaço de Tuplas
import net.jini.space.JavaSpace;
import java.util.Scanner;
public class WriteMessage {
public static void main(String[] args) {
try {
System.out.println("Procurando pelo serviço JavaSpace...");
Lookup finder = new Lookup(JavaSpace.class);
JavaSpace space = (JavaSpace) finder.getService();
if (space == null) {
System.out.println("O serviço JavaSpace não foi encontrado. Encerrando...");
System.exit(-1); }
System.out.println("O serviço JavaSpace foi encontrado.");
Scanner scanner = new Scanner(System.in);
while (true) {
System.out.print("Entre com o texto da mensagem (ENTER para sair): ");
String message = scanner.nextLine();
if (message == null || message.equals("")) {
System.exit(0); }
Message msg = new Message();
msg.content = message;
space.write(msg, null, 60 * 1000); }
} catch (Exception e) { e.printStackTrace(); } } }
// Lendo Mensagens do Espaço de Tuplas
import net.jini.space.JavaSpace;
public class ReadMessage {
public static void main(String[] args) {
try {
System.out.println("Procurando pelo serviço JavaSpace...");
Lookup finder = new Lookup(JavaSpace.class);
JavaSpace space = (JavaSpace) finder.getService();
if (space == null) {
System.out.println("O serviço JavaSpace não foi encontrado. Encerrando...");
System.exit(-1); }
System.out.println("O serviço JavaSpace foi encontrado.");
while (true) {
Message template = new Message();
Message msg = (Message) space.take(template, null, 60 * 1000);
if (msg == null) {
System.out.println("Tempo de espera esgotado. Encerrando...");
System.exit(0); }
System.out.println("Mensagem recebida: "+ msg.content) }
} catch (Exception e) {
e.printStackTrace(); } } }
• Linda
Linda possui seis operações apenas, duas de escrita (out e eval) e quatro de leitura (in, inp, rd e rdp). Nesta seção, a apresentação das operações é acompanhada por exemplos escritos em C-Linda.
• Operação para colocar tuplas no TS (Espaço de tuplas – Tuplas Spaces)
- OUT (expr1, expr2,..., exprn) -> tupla adicionada ao espaço de tuplas
• Operação para retirar tuplas de TS
- IN (c1, c2,..., cn) -> tupla satisfazendo template é retirada do espaço de tuplas
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
INT A, B
A=5
IN ("sinal", 5, ?B) ou IN ("sinal", A, ?B)
Depois da execução: B=3 e tupla não existe mais.
• Operação para consultar tupla em TS
- RD (c1, c2,..., cn) -> tupla é lida, mas permanece no espaço de tuplas
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
INT A, B
A=5
RD("sinal",5,?B) ou RD("sinal",A,?B)
Depois da execução: B=3 e tupla permanece em TS
• Tanto o IN como o RD são “bloqueantes” os processos ficam bloqueados até que apareça no espaço de tuplas, uma tupla que case com a pedida.
• Operação para criar um novo processo: Concorrência
- EVAL (c1, c2,..., cn) -> funciona como out, mas um novo processo é criado para associar a tupla.
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
EVAL ("novoproc", x, f(x))
Depois da execução: Um novo processo é criado para executar f(x).
• Lime
Lime (Linda in a Mobile Environment) é um middleware projetado para possibilitar o desenvolvimento rápido de aplicações que apresentam mobilidade física (hosts) e/ou lógica (agentes). Ele adapta o espaço de tuplas do Linda para ambientes móveis através da quebra da noção de um espaço de tuplas global, ou seja, o conteúdo encontra-se distribuído através dos múltiplos componentes móveis.
Em Lime, cada agente possui espaços de tuplas próprios, que ele leva consigo a tiracolo, chamados ITS (interface tuplespace). Quando o agente se fixa em um host, seus ITSs são fundidos a um espaço de tuplas local e as tuplas passam a ficar visíveis para os demais agentes acoplados ao host. Ao deixar o host, o agente leva consigo os ITSs com as tuplas.
• Links
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/ (espaços de tuplas)
http://www.inf.ufsc.br/~frank/INE6514/JavaSpaces/ (javaspaces)
http://www.inf.puc-rio.br/~noemi/victal/linda.html (linda)
http://www.cin.ufpe.br/~vvs/cows/cowsPaper.pdf (Lime)
Um espaço de tuplas tem como função criar uma abstração de memória compartilhada sobre um sistema distribuído, onde todos podem ler e escrever no mesmo. Porém, na realidade os objetos estão dispostos nas memórias dos nós de cada sistema distribuído.
IMPLEMENTAÇÕES
• JavaSpaces
O espaço de tuplas JavaSpaces é um dos mais populares espaços de tuplas para a linguagem Java. As instruções abaixo descrevem como criar programas que compartilhem memória utilizando o JavaSpaces. Será utilizada a implementação do JavaSpaces do JINI e uma classe auxiliar para conectar ao serviço JavaSpace.
Código:
// Definindo o Formato das Mensagens
import net.jini.core.entry.Entry;
public class Message implements Entry {
public String content;
public Message() { } }
// Escrevendo no Espaço de Tuplas
import net.jini.space.JavaSpace;
import java.util.Scanner;
public class WriteMessage {
public static void main(String[] args) {
try {
System.out.println("Procurando pelo serviço JavaSpace...");
Lookup finder = new Lookup(JavaSpace.class);
JavaSpace space = (JavaSpace) finder.getService();
if (space == null) {
System.out.println("O serviço JavaSpace não foi encontrado. Encerrando...");
System.exit(-1); }
System.out.println("O serviço JavaSpace foi encontrado.");
Scanner scanner = new Scanner(System.in);
while (true) {
System.out.print("Entre com o texto da mensagem (ENTER para sair): ");
String message = scanner.nextLine();
if (message == null || message.equals("")) {
System.exit(0); }
Message msg = new Message();
msg.content = message;
space.write(msg, null, 60 * 1000); }
} catch (Exception e) { e.printStackTrace(); } } }
// Lendo Mensagens do Espaço de Tuplas
import net.jini.space.JavaSpace;
public class ReadMessage {
public static void main(String[] args) {
try {
System.out.println("Procurando pelo serviço JavaSpace...");
Lookup finder = new Lookup(JavaSpace.class);
JavaSpace space = (JavaSpace) finder.getService();
if (space == null) {
System.out.println("O serviço JavaSpace não foi encontrado. Encerrando...");
System.exit(-1); }
System.out.println("O serviço JavaSpace foi encontrado.");
while (true) {
Message template = new Message();
Message msg = (Message) space.take(template, null, 60 * 1000);
if (msg == null) {
System.out.println("Tempo de espera esgotado. Encerrando...");
System.exit(0); }
System.out.println("Mensagem recebida: "+ msg.content) }
} catch (Exception e) {
e.printStackTrace(); } } }
• Linda
Linda possui seis operações apenas, duas de escrita (out e eval) e quatro de leitura (in, inp, rd e rdp). Nesta seção, a apresentação das operações é acompanhada por exemplos escritos em C-Linda.
• Operação para colocar tuplas no TS (Espaço de tuplas – Tuplas Spaces)
- OUT (expr1, expr2,..., exprn) -> tupla adicionada ao espaço de tuplas
• Operação para retirar tuplas de TS
- IN (c1, c2,..., cn) -> tupla satisfazendo template é retirada do espaço de tuplas
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
INT A, B
A=5
IN ("sinal", 5, ?B) ou IN ("sinal", A, ?B)
Depois da execução: B=3 e tupla não existe mais.
• Operação para consultar tupla em TS
- RD (c1, c2,..., cn) -> tupla é lida, mas permanece no espaço de tuplas
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
INT A, B
A=5
RD("sinal",5,?B) ou RD("sinal",A,?B)
Depois da execução: B=3 e tupla permanece em TS
• Tanto o IN como o RD são “bloqueantes” os processos ficam bloqueados até que apareça no espaço de tuplas, uma tupla que case com a pedida.
• Operação para criar um novo processo: Concorrência
- EVAL (c1, c2,..., cn) -> funciona como out, mas um novo processo é criado para associar a tupla.
• Exemplo:
Tupla em TS: ("sinal",5,3)
Código:
EVAL ("novoproc", x, f(x))
Depois da execução: Um novo processo é criado para executar f(x).
• Lime
Lime (Linda in a Mobile Environment) é um middleware projetado para possibilitar o desenvolvimento rápido de aplicações que apresentam mobilidade física (hosts) e/ou lógica (agentes). Ele adapta o espaço de tuplas do Linda para ambientes móveis através da quebra da noção de um espaço de tuplas global, ou seja, o conteúdo encontra-se distribuído através dos múltiplos componentes móveis.
Em Lime, cada agente possui espaços de tuplas próprios, que ele leva consigo a tiracolo, chamados ITS (interface tuplespace). Quando o agente se fixa em um host, seus ITSs são fundidos a um espaço de tuplas local e as tuplas passam a ficar visíveis para os demais agentes acoplados ao host. Ao deixar o host, o agente leva consigo os ITSs com as tuplas.
• Links
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/ (espaços de tuplas)
http://www.inf.ufsc.br/~frank/INE6514/JavaSpaces/ (javaspaces)
http://www.inf.puc-rio.br/~noemi/victal/linda.html (linda)
http://www.cin.ufpe.br/~vvs/cows/cowsPaper.pdf (Lime)
Implementação de espaços de tuplas do tipo JavaSpaces
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. Processos distintos do sistema podem executar uma tarefa comum, usando o espaço de tuplas como meio de comunicação, coordenação e sincronização.
A união do modelo de espaço de tuplas com a linguagem Java trouxe benefícios sensíveis.
A linguagem Java tem características que favorecem o desenvolvimento de aplicações distribuídas, dentre elas a portabilidade, o suporte natural à movimentação de código e a segurança. Não é à toa que Java vem sendo a linguagem de escolha em algumas categorias de aplicações distribuídas tais como agentes móveis.
JavaSpaces é uma especificação. Isso quer dizer que pode haver mais de uma implementação para JavaSpaces.
A especificação JavaSpaces está fortemente vinculada ao sistema Jini, também de autoria da Sun. O Jini consiste em uma infra-estrutura que pretende simplificar o desenvolvimento, instalação e administração de sistemas distribuídos. O Jini é baseado na linguagem Java.
Jini é uma das mais concretas propostas no sentido de se implementar sistemas computacionais que possam ser mantidos com pouca ou quase nenhuma intervenção humana.
É difícil encontrar uma implementação satisfatória de JavaSpaces. As implementações atuais oferecem funcionalidades especiais, cada uma a seu modo, mas mesmo assim, ainda requerem a infra-estrutura Jini. Outra restrição que atinge a todos, é que, como produtos de software, esses espaços de tuplas possuem licenças proprietárias. Atualmente é possível adquirir cópias gratuitas pela Internet, mas não há garantias que isso permanecerá assim indefinidamente.
Fonte: http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/
Francino Neto 103041061
A união do modelo de espaço de tuplas com a linguagem Java trouxe benefícios sensíveis.
A linguagem Java tem características que favorecem o desenvolvimento de aplicações distribuídas, dentre elas a portabilidade, o suporte natural à movimentação de código e a segurança. Não é à toa que Java vem sendo a linguagem de escolha em algumas categorias de aplicações distribuídas tais como agentes móveis.
JavaSpaces é uma especificação. Isso quer dizer que pode haver mais de uma implementação para JavaSpaces.
A especificação JavaSpaces está fortemente vinculada ao sistema Jini, também de autoria da Sun. O Jini consiste em uma infra-estrutura que pretende simplificar o desenvolvimento, instalação e administração de sistemas distribuídos. O Jini é baseado na linguagem Java.
Jini é uma das mais concretas propostas no sentido de se implementar sistemas computacionais que possam ser mantidos com pouca ou quase nenhuma intervenção humana.
É difícil encontrar uma implementação satisfatória de JavaSpaces. As implementações atuais oferecem funcionalidades especiais, cada uma a seu modo, mas mesmo assim, ainda requerem a infra-estrutura Jini. Outra restrição que atinge a todos, é que, como produtos de software, esses espaços de tuplas possuem licenças proprietárias. Atualmente é possível adquirir cópias gratuitas pela Internet, mas não há garantias que isso permanecerá assim indefinidamente.
Fonte: http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08032003-012015/
Francino Neto 103041061
quinta-feira, 4 de setembro de 2008
Espaços de Tuplas
RESUMO
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.
O primeiro espaço de tuplas recebeu o nome de Linda [Gelernter, 1985]. Ele trabalha em associação com diversas linguagens de programação, em especial, com as linguagens C e Fortran, as mais usadas em análise numérica e computação paralela. Não tardou, surgiram outros espaços de tuplas, quase sempre acrescentando alguma variante ao modelo básico implementado em Linda.
Lime (Linda in a Mobile Environment) [Picco et al, 1998] é um espaço de tuplas voltado para agentes e computação móvel. Esse é um nicho de aplicação propício para os espaços de tuplas. Lime mostra como o conceito básico de espaço de tuplas pode ser adaptado criativamente para aplicações com demandas específicas. Em Lime, cada agente possui espaços de tuplas próprios, que ele leva consigo a tiracolo, chamados ITS (interface tuple
space). Quando o agente se fixa em um host, seus ITSs são fundidos a um espaço de tuplas local e as tuplas passam a ficar visíveis para os demais agentes acoplados ao host. Ao deixar o host, o agente leva consigo os ITSs com as tuplas.
Ruple [Rogue Wave, 2001] é um espaço de tuplas voltado para a troca de documentos pela Internet. A grande inovação de Ruple é a definição de tupla, que não possui campos como uma tupla de Linda. As tuplas de Ruple são documentos em XML. No entanto, a recuperação das tuplas permanece sendo feita por conteúdo, usando consultas expressas na linguagem XQL. Outras características interessantes são: o protocolo SOAP para comunicação por rede, o uso de leasing para automanutenção e certificação X.509 para segurança.
Em resumo, o modelo de espaço de tuplas é um mecanismo com semântica de memória compartilhada que pode ser acessado concorrentemente por processos espalhados em um sistema distribuído. O modelo implementa um esquema de memória associativa. Duas propriedades do modelo de espaço de tuplas destacam-se: a simplicidade e o baixo acoplamento entre os processos. Juntas, elas dão ao modelo uma vantagem em termos de facilidade de desenvolvimento e manutenção das aplicações.
O primeiro espaço de tuplas recebeu o nome de Linda [Gelernter, 1985]. Ele trabalha em associação com diversas linguagens de programação, em especial, com as linguagens C e Fortran, as mais usadas em análise numérica e computação paralela. Não tardou, surgiram outros espaços de tuplas, quase sempre acrescentando alguma variante ao modelo básico implementado em Linda.
Lime (Linda in a Mobile Environment) [Picco et al, 1998] é um espaço de tuplas voltado para agentes e computação móvel. Esse é um nicho de aplicação propício para os espaços de tuplas. Lime mostra como o conceito básico de espaço de tuplas pode ser adaptado criativamente para aplicações com demandas específicas. Em Lime, cada agente possui espaços de tuplas próprios, que ele leva consigo a tiracolo, chamados ITS (interface tuple
space). Quando o agente se fixa em um host, seus ITSs são fundidos a um espaço de tuplas local e as tuplas passam a ficar visíveis para os demais agentes acoplados ao host. Ao deixar o host, o agente leva consigo os ITSs com as tuplas.
Ruple [Rogue Wave, 2001] é um espaço de tuplas voltado para a troca de documentos pela Internet. A grande inovação de Ruple é a definição de tupla, que não possui campos como uma tupla de Linda. As tuplas de Ruple são documentos em XML. No entanto, a recuperação das tuplas permanece sendo feita por conteúdo, usando consultas expressas na linguagem XQL. Outras características interessantes são: o protocolo SOAP para comunicação por rede, o uso de leasing para automanutenção e certificação X.509 para segurança.
Em resumo, o modelo de espaço de tuplas é um mecanismo com semântica de memória compartilhada que pode ser acessado concorrentemente por processos espalhados em um sistema distribuído. O modelo implementa um esquema de memória associativa. Duas propriedades do modelo de espaço de tuplas destacam-se: a simplicidade e o baixo acoplamento entre os processos. Juntas, elas dão ao modelo uma vantagem em termos de facilidade de desenvolvimento e manutenção das aplicações.
Assinar:
Comentários (Atom)