Uma arquitetura de middleware para suporte a aplicações
colaborativas de tinta digital
Lucas L. Provensi1 , Fabio M. Costa1 , Vagner Sacramento1
1
Instituto de Informática – Universidade Federal de Goiás (UFG)
Goiânia – GO – Brasil
{lucas,fabio,vagner}@inf.ufg.br
Abstract. Communication is a key aspect in collaborative systems, and should
enable effective and quality interaction between users. Conventional communication solutions for collaborative applications do not address the dynamism of
some network environments, such as the mobile computing. This article provides
a middleware infrastructure capable of adapting itself in response to changes in
its execution environment in order to maintain the quality of communication in
collaborative systems, with specific interest in applications based on tablet PCs
and digital ink.
Resumo. A comunicação é um dos aspectos fundamentais em sistemas colaborativos, e deve possibilitar uma interação efetiva e de qualidade entre os
usuários. Soluções convencionais de comunicação para aplicações colaborativas não tratam o dinamismo de alguns ambientes de rede, como o ambiente de
computação móvel. Este artigo apresenta uma infra-estrutura de middleware
capaz de se adaptar a variações em seu ambiente de execução para manter a
qualidade da comunicação em sistemas colaborativos, com interesse especı́fico
em aplicações de tinta digital em tablet PCs.
1. Introdução
Sistemas computacionais colaborativos são ferramentas projetadas para auxiliar um grupo
de pessoas a realizar uma tarefa ou alcançar um objetivo comum [Ellis et al. 1991]. Esses
sistemas constituem um ambiente interativo de trabalho, onde a colaboração é determinada pela junção efetiva de comunicação, coordenação e cooperação [Fuks et al. 2005].
A comunicação nos sistemas colaborativos, quando feita de maneira coordenada,
fornece o meio de troca de informações que viabiliza a cooperação em um grupo. Entretanto, em um ambiente dinâmico, como dispositivos móveis em uma rede sem fio, a
qualidade do canal de comunicação varia ao longo da execução do sistema. Se não houver
um tratamento adequado, a interação entre os participantes pode ser afetada.
Existem ainda dispositivos móveis, como os Tablet PCs, que oferecem uma interface de interação diferente da convencional, semelhante à escrita humana, onde o usuário
utiliza uma caneta para escrever sobre a tela do computador. Esta tecnologia de entrada de
dados, conhecida como tinta digital, permite ao usuário esquematizar e representar suas
idéias de forma mais natural do que utilizando o mouse ou o teclado. A tinta digital pode
ser aplicada a sistemas colaborativos para criar ambientes de trabalho mais eficazes, onde
os usuários possuem liberdade para se expressar através da escrita e de desenhos.
Neste artigo, a tinta digital é tratada como um tipo de mı́dia, pois possui caracterı́sticas comuns a outros tipos de mı́dia, como áudio e video. Uma dessas caracterı́sticas
é a sensibilidade ao tempo, onde a coordenação das atividades depende da comunicação
da tinta para todos usuários ao mesmo tempo, ou com um atraso mı́nimo. Em aplicações
baseados em tinta digital, a qualidade do canal de comunicação é o principal fator que
determina o compartilhamento da tinta em tempo real.
Para manter o aspecto de tempo real em um ambiente dinâmico, o mecanismo
de comunicação deve ser flexı́vel o bastante para possibilitar adaptações em tempo de
execução. Mais que isso, o sistema deve estar ciente das variáveis do ambiente de rede
que afetam a qualidade da comunicação para tomar ações corretivas de forma autônoma.
Desta forma o sistema pode identificar problemas como o atraso na recepção dos pacotes contendo tinta digital e tomar alguma providência, como utilizar compressão para
diminuir o tráfego na rede.
Visando dar suporte a colaboração em tempo real para aplicações baseadas em
tinta digital, este artigo propõe uma infra-estrutura de middleware capaz de tratar automaticamente os problemas de comunicação encontrados em ambientes de rede dinâmicos.
Além disso, são apresentados experimentos com a tinta digital, que avaliam os efeitos de
seu tratamento como um tipo de mı́dia e os impactos do seu compartilhamento em um
ambiente de computação móvel.
Este trabalho está estruturado como se segue. A Seção 2 caracteriza aplicações
colaborativas baseadas em tinta digital e seus requisitos. A Seção 3 apresenta o modelo
de middleware adotado para tratar os aspectos de comunicação encontrados nesse tipo
de aplicação, enquanto a Seção 4 propõe extensões para possibilitar a auto-adaptação do
middleware. A Seção 5 apresenta uma comparação com trabalhos relacionados e por fim,
a Seção 6 discute os impactos da abordagem adotada.
2. Aplicações Colaborativas baseadas em tinta digital
O desenho e a escrita são atividades realizadas naturalmente pelas pessoas para organizar idéias sem se preocupar com a precisão com que as mesmas são representadas
[Hong and Landay 2000]. Modelos podem ser desenhados para esquematizar objetos
reais, conceitos podem ser escritos para memorização, associações entre idéias podem
ser facilmente visualizadas.
Com o intuito de tornar a interação homem-computador mais natural, surgiram os
dispositivos computacionais equipados com caneta e as aplicações baseadas em tinta digital. O restante desta seção caracteriza com mais detalhes a tinta digital, mostrando como
essa tecnologia pode ser aplicada em sistemas colaborativos e quais são os problemas de
comunicação que podem afetar a interação em sistemas desse tipo.
2.1. Tinta Digital
Computadores portáteis conhecidos como Tablet PCs são equipados com um hardware
especial, constituı́do de uma caneta e um digitalizador em sua tela. O movimento e o
contato da caneta com a superfı́cie da tela é capturado pelo digitalizador, formando o que
se convencionou chamar de tinta digital, que consiste, essencialmente, na representação
dos traços realizados com a caneta. Além disso, esses dispositivos contam com as van-
tagens oferecidas pelo poder computacional, mobilidade e conectividade equivalentes às
dos laptops.
O digitalizador coleta informações sobre as coordenadas da ponta da caneta durante sua movimentação, bem como a pressão no ponto de contato da caneta com a
superfı́cie da tela. Essas informações consistem em seqüencias numéricas que são armazenadas em estruturas conhecidas como pacotes de tinta. Os pacotes são analizados
por software, que renderiza a imagem desenhada com a caneta na tela do tablet PC em
tempo real.
A tinta digital é formada por estruturas que representam riscos feitos com a caneta,
ou strokes, que contém os pacotes de tinta coletados durante cada contato da caneta com
a superfı́cie da tela. Os riscos que formam a tinta digital podem ser interpretados pelas
aplicações de diversas maneiras, como por exemplo no reconhecimento de escrita e de
formas geométricas, onde a tinta coletada é transformada em texto ou em objetos gráficos.
Até mesmo a seqüência de gestos com a caneta pode ser convertida em dados de entrada
para as aplicações.
Pesquisas sobre a tinta digital vêm sendo realizadas há algum tempo, como em
[Poon et al. 1995], que descreve uma ferramenta de busca de padrões em tinta digital e
em [Chiu et al. 1999], que trata da utilização da tinta em conjunto com vı́deo em uma sala
de conferência. Este último explora aspectos interativos da tinta, que pode ser utilizada
como uma ferramenta simples de tomada de notas durante uma conferência.
Pesquisas atuais exploram outros aspectos da tinta digital, como o aspecto temporal [Rieffel and Toomey 2007], que define o momento e a ordem em que cada anotação
com a caneta foi realizada. Em [Cattelan et al. 2008] é proposto um player para aprimorar
a visualização de anotações de tinta digital sobre documentos, onde a tinta armazenada
pode ser revista de maneira interativa.
2.2. Aplicação em sistemas colaborativos
A tinta digital proporciona uma forma de tomar notas próxima da convencional. Assim, os tablet PCs podem ser usados de maneira mais intuitiva que computadores com
dispositivos de interação convencionais. Diversas aplicações podem tirar proveito dessa
tecnologia, como por exemplo aquelas destinadas ao ensino.
Ao contrário do modelo tradicional de ensino, que consiste em transmissão unidirecional de conhecimento do professor para os alunos, o modelo ativo e colaborativo
de ensino é mais efetivo e melhor aceito pelos alunos [Prince 2004]. As ferramentas
computacionais de apoio ao ensino se voltaram para esse modelo, buscando maior interatividade.
A criação de documentos em sala de aula pode se tornar uma atividade colaborativa, onde cada participante pode gravar uma cópia, modificá-la e alterá-la, sozinho ou
em grupo. Deste modo, a informação passa a ser compartilhada de forma bi-direcional
[Berque et al. 2004].
Aplicações computacionais já utilizadas em sala de aula, como um recurso audiovisual, podem se tornar interativas através da tinta digital. O Classroom Presenter
[Anderson et al. 2004] é um exemplo, onde o modelo tradicional de apresentação de
slides é aprimorado com a possibilidade de anotações em tempo real sobre a apresentação,
tanto por parte dos alunos como por parte do professor.
O quadro branco compartilhado é outro exemplo de aplicação da tinta digital e
é o foco do eexperimento apresentado neste artigo. O quadro branco pode ser utilizado
tanto em sala de aula quanto em outras atividades onde é importante uma área compartilhada para anotações. A idéia da utilização do quadro branco como recurso computacional não é nova [Berque et al. 2001]. Porém nossa abordagem visa tratar os aspectos de
comunicação que podem afetar um sistema desta natureza.
Em comparação com um quadro branco real, o quadro branco computacional apresenta algumas vantagens, como a manipulação direta da tinta para operações de escala,
recorte, movimentação e alteração de propriedades como cor e estilo dos traços, além da
possibilidade de gravá-la para consulta futura. Um protótipo do quadro branco foi criado
para testar as propriedades desse tipo de ambiente e é mostrado na Figura 1.
Figure 1. Quadro branco compartilhado.
Nesta aplicação, um usuário pode dar inı́cio a uma seção escolhendo os outros
usuários que farão parte do grupo colaborativo. Em uma sala de aula, por exemplo,
o professor pode formar grupos de alunos que vão trabalhar em conjunto para resolver
um exercı́cio proposto. Todos os alunos do grupo podem fazer contribuições no quadro
branco com a tinta digital, podendo configurar a cor, tamanho, transparência, entre outras
propriedades da tinta. As contribuições de cada participante do grupo são replicadas para
os demais em tempo real.
Neste protótipo, a tinta é transferida por cada usuário para os demais à medida em
que é coletada, sem nenhum tratamento, através de uma rede sem fio. Sem um tratamento
adequado, problemas tı́picos de rede, tais como atraso e perdas de pacotes, podem causar
respectivamente falhas na coordenação de atividades e na representação da tinta.
2.3. Problemas que afetam a interação
O ambiente de rede sem fio, apesar dos benefı́cios oferecidos pela mobilidade, possui uma série de limitações em comparação com as redes cabeadas. Largura de banda
menor, maior taxa de erros e desconexão abrupta são alguns dos problemas encontrados
neste tipo de ambiente [Forman and Zahorjan 1994]. Esses problemas tendem a afetar a
comunicação em aplicações distribuı́das, pois causam perdas e atraso dos pacotes enviados pela rede.
Foram realizados experimentos em uma rede 802.11a, fazendo o monitoramento
dos pacotes de dados enviados pela rede, utilizando tamanhos de pacote similares ao
tamanho tı́pico dos pacotes de tinta digital gerados pelo quadro branco compartilhado.
Uma aplicação de monitoramento foi desenvolvido para os experimentos, que foram feitos
em uma sala de aula enquanto os alunos faziam uso de tablet PCs com uma aplicação de
apoio a apresentação de slides em rede. A aplicação gera fluxos de pacotes entre dois
pontos da rede, coletando informações sobre o atraso e a perda de pacotes nesse fluxo.
Os experimentos mostraram que, para o ambiente em questão, existe normalmente
um atraso médio de 88ms e uma percentagem de perda de pacotes de 4%. Já em momentos de uso intensivo dos tablet PCs e da rede, o atraso médio passou para 215ms com picos
de até 1400ms e uma percentagem de perda de pacotes de 21% com picos que chegaram
a 8 pacotes perdidos em sequência.
Os dados coletados no experimento foram usados em uma aplicação de simulação
desenvolvida para verificar os efeitos do atraso e da perda de pacotes na comunicação da
tinta digital, o que é feito em um único tablet PC, sem a necessidade de um ambiente
de rede. Essa aplicação recebe como parâmetro o atraso médio e a freqüência perda
de pacotes. Esses parâmetros são aplicados na tinta digital coletada em um painel da
aplicação e os efeitos podem ser vistos simultaneamente em outro painel. Os efeitos
observados na simulação são discutidos a seguir.
O problema do atraso afeta diretamente a coordenação das atividades. No quadro
branco compartilhado, por exemplo, o professor pode estar falando enquanto escreve no
quadro. Se houver atraso na recepção da tinta pelos alunos, aquilo que o professor fala
pode parecer fora de sincronia com o que ele escreve.
A Figura 2 mostra uma simulação realizada com os dados de atraso obtidos nos
experimentos. Considerando o cenário do quadro branco em sala de aula, a figura do
painel esquerdo seria a visão do professor e a do painel direito a do aluno em um mesmo
momento. Em decorrência do atraso, o aluno pode estar ouvindo uma explicação sobre
algo que ainda não aparece em sua cópia do quadro branco.
Figure 2. Atraso na recepção de pacotes de tinta digital
Já as perdas de pacotes afetam a representação estática da tinta em um determinado momento. Como os pacotes de tinta consistem em dados de coordenadas, os trechos
de tinta formados por essas coordenadas são perdidos. Por exemplo, se houver perdas de
pacotes contendo determinados trechos de palavras, uma frase escrita no quadro branco
pelo professor pode se tornar incompreensı́vel para os alunos.
A Figura 3 ilustra essa situação através da simulação feita com os dados colhidos
de perda de pacotes. A figura do painel da esquerda mostra a tinta produzida pelo professor e a do painel da direita mostra como essa tinta seria visualizada pelos alunos, com
perdas que podem comprometer seu entendimento.
Figure 3. Efeito da perda de pacotes de tinta digital.
Em nossa abordagem, tratamos a tinta digital como um novo tipo de mı́dia devido
à sua semelhança com outros tipos como audio e vı́deo [Lopresti 1998]. Essas mı́dias,
em aplicações de tempo real, apresentam uma certa tolerância a atrasos e perdas. Atrasos
mı́nimos em sua recepção, assim como pequenas perdas, podem não ser percebidos pelos
usuários. Porém quando o atraso e as perdas aumentam, o usuário perde a sensação de
recepção em tempo real da mı́dia e não consegue entender seu conteúdo.
Soluções de comunicação para aplicações de audio e vı́deo em tempo real adotam
estratégias para contornar esses problemas, como diminuir a qualidade de codificação da
mı́dia, o que reduz a quantidade de dados trafegados na rede. Em contraste, os mecanismos de comunicação usados tradicionalmente para transmissão de tinta digital não possuem essa preocupação e, portanto, não são adequados para garantir a interação em tempo
real nas aplicações colaborativas. A seguir, discutiremos uma proposta para introduzir
tratamento de QoS nesse tipo de aplicação.
3. Suporte de middleware para aplicações colaborativas
Os problemas do ambiente de rede, como atraso e perdas, não podem ser avaliados
antes da execução da aplicação, pois podem variar ao longo do tempo. Sendo assim,
é necessário o monitoramento contı́nuo da qualidade da rede para identificar esses problemas. Uma vez identificados os problemas, a aplicação precisa modificar seu comportamento para se adequar às novas caracterı́sticas da rede. Para isto, a aplicação precisa
inspecionar e adaptar sua estrutura interna em tempo de execução [Blair et al. 1997].
A adaptação tratada no nı́vel das aplicações aumenta a complexidade e o esforço
de desenvolvimento. Sendo assim, esse tratamento é mais adequado ao middleware, que
consiste em uma camada de software que não afeta a lógica da aplicação, usada para
tratar os aspectos de comunicação envolvidos em um sistema distribuı́do. Neste sentido, uma plataforma de middleware pode oferecer os mecanismos de adaptação dinâmica
necessários para manter a qualidade da comunicação em ambientes de rede dinâmicos.
A arquitetura proposta utiliza e estende a plataforma de middleware reflexivo Meta-ORB [Costa 2002] com a finalidade de tratar os problemas do canal de
comunicação, como o atraso e a perda de pacotes, em aplicações colaborativas. O
restante desta seção discute como os aspectos de configurabilidade e adaptabilidade da
plataforma Meta-ORB podem ser empregados no desenvolvimento de aplicações colaborativas baseadas em tinta digital.
3.1. Configurabilidade
A configurabilidade, nas plataformas de middleware, permite que soluções de
comunicação sejam customizadas para atender as necessidades especı́ficas de cada tipo
aplicação, sem a necessidade de modificar e recompilar seu código. Na plataforma
Meta-ORB, a configurabilidade se deve ao seu modelo de programação baseado em
componentes. Os componentes são entidades executáveis de software, projetadas para
reutilização e combinação [Szyperski 1998], que podem ser usados para formar uma
configuração de middleware.
Considerando uma aplicação baseada em tinta digital, aspectos distintos como
captura, serialização, empacotamento e envio da tinta são separados em diferentes componentes. Esses componentes podem ser combinados para formar uma configuração, podendo ser substituı́dos ou reutilizados em configurações para outros tipos de aplicação.
A Figura 4 ilustra a configuração de uma aplicação baseada em tinta digital, como
o quadro branco compartilhado apresentado na Seção 2.2. Na figura, os componentes da
aplicação são responsáveis pela coleta e tratamento da tinta digital. Esses componentes
possuem interfaces bem definidas para a transmissão e recepção de tinta, que podem ser
ligadas entre si por meio de uma estrutura conhecida como binding. Neste caso, o binding
é a solução de comunicação adotada e consiste em uma configuração de componentes criada de forma independente da aplicação para serializar e enviar pacotes de dados contendo
tinta digital.
Figure 4. Configuração de uma aplicação baseada em tinta digital.
A plataforma conta ainda com um sistema de tipos, implementado como um
repositório global [Costa et al. 2007], para a definição e recuperação da definição de
configurações e seus componentes e interfaces. Assim, a configuração que forma o binding da Figura 4 é definida no repositório e fica disponı́vel para todas as aplicações que precisam de suporte a fluxos de tinta digital. Quando a aplicação é executada, a plataforma
busca no repositório a definição do binding e utiliza fábricas especializadas para instanciar
a configuração de componentes que o forma.
3.2. Adaptação dinâmica
A configurabilidade oferecida pelo modelo de componentes permite a instanciação
estática de configurações especializadas da plataforma. Porém, torna-se necessário um
mecanismo para reconfiguração dinâmica, uma vez que os requisitos da aplicação podem
variar durante seu tempo de execução, assim como as condições da rede e do ambiente de
execução, como visto na Seção 2.3.
Com esta finalidade, a plataforma Meta-ORB emprega o conceito de reflexão computacional. Segundo [Maes 1987] reflexão consiste em manter uma auto-representação
causalmente conectada ao sistema, de modo que mudanças nesta auto-representação
afetem o sistema em si e vice-versa.
Em plataformas de middleware, a reflexão é utilizada para inspeção e adaptação
do sistema em tempo de execução [Coulson 2001]. Na plataforma MetaORB, o sistema é
dividido em um nı́vel base, contendo os componentes da aplicação, e um meta-nı́vel, que
é sua auto-representação causalmente conectada.
O meta-nı́vel é povoado por meta-componentes que fazem uso das definições
guardadas no repositório de tipos para manter uma auto-representação do nı́vel base.
Assim como os componentes, os meta-componentes possuem interfaces bem definidas.
Através dessas interfaces, é possı́vel inspecionar o nı́vel base e requisitar reconfigurações
de componentes.
A Figura 5 mostra a reconfiguração do binding apresentado na Seção 3.1. Uma
requisição de reconfiguração é feita ao meta-componente associado ao binding, a qual
pode consistir na substituição dos componentes do binding responsáveis pela serialização
ou pelo envio dos pacotes de tinta. O meta-componente inicia então a substituição dos
componentes do nı́vel base por novos componentes para formar um novo binding que
atenda as necessidades da aplicação.
Figure 5. Meta-componente realizando uma adaptação.
4. Extensões para suporte à auto-adaptação
Os problemas de atraso e perdas descritos anteriormente ocorrem principalmente devido a variações imprevistas na qualidade da rede. Entretanto, seria inconveniente para o
usuário ter que requisitar explicitamente uma adaptação quando percebe uma degradação
da caracterı́stica de tempo real da aplicação. Ao invés disso, o sistema deveria inferir o
momento certo, monitorando mudanças no ambiente de rede, e disparando a adaptação
de modo transparente ao usuário.
A plataforma Meta-ORB oferece o mecanismo necessário para adaptação
dinâmica, mas em sua implementação atual, a iniciativa para realizar essa adaptação deve
deve vir da própria aplicação. Para possibilitar sua reutilização, facilitar sua análise e sua
evolução, assim como automatizar seu gerenciamento, o mecanismo de adaptação deve
ser separado do restante do sistema [Schmerl and Garlan 2002].
Para reagir a mudanças indesejáveis no ambiente de rede, como aumento do
atraso e das perdas de pacotes, a plataforma Meta-ORB deve ser complementada com
um mecanismo de adaptação automático e independente da aplicação. Com esta finalidade, propomos extensões em sua arquitetura para a gerência automática de adaptação, as
quais serão descritas no restante desta seção.
4.1. Monitoramento de Contexto
Como visto na Seção 3.1, o repositório de tipos guarda as definições das configurações
que podem ser utilizadas para instanciar o middleware. Uma configuração é definida
no repositório na forma de meta-informações a respeito dos componentes, interfaces e
bindings que a compõem. Interfaces definidas no repositório, como as de fluxo de tinta
da Figura 4, podem conter ainda meta-informações a respeito da qualidade de serviço
esperada por aquele tipo de interface. Assim, o fluxo através de um binding pode ficar
restrito ao nı́vel de QoS definido nas interfaces participantes.
Na definição das interfaces utilizadas na aplicação do quadro branco, por exemplo,
podem existir atributos de QoS que definem o valor médio de atraso e a percentagem
de perdas aceitáveis para uma aplicação daquele tipo. Componentes especializados para
monitoramento de contexto podem checar mudanças no ambiente de rede para determinar
violações nos atributos de QoS.
Durante a criação do binding, se as interfaces que serão ligadas possuem restrições
de QoS, então os monitores de contexto são instanciados pelas fábricas para coletar dados
do ambiente de rede. Esses dados podem ser utilizados para identificar possı́veis violações
de QoS no fluxo de tinta entre as interfaces.
4.2. Gerenciamento de adaptação
Os dados coletados pelos monitores de contexto são avaliados por um gerenciador de
adaptação global associado a um binding. O gerenciador, verifica se os requisitos de QoS
das interfaces estão sendo atendidos. Caso contrário, ele deve tomar providências para
contornar a situação. A ação a ser tomada pode ser obtida no repositório de tipos, na
forma de uma polı́tica de adaptação para tratar o atributo de QoS violado.
Assim como os atributos de QoS, as polı́ticas de adaptação são meta-informações
guardadas no repositório de tipos. Cada binding pode definir uma série de polı́ticas associadas a um fluxo de interesse e cada polı́tica é formada por regras que podem ser aplicadas
para adaptar a estrutura do binding. As regras definem apenas quais operações do metacomponente associado ao binding devem ser chamadas juntamente com seus argumentos.
Para o quadro branco, por exemplo, as interfaces de fluxo de tinta são definidas
no repositório contendo atributos de QoS relativos ao atraso e a perdas, restringindo,
por exemplo, o atraso médio a 1 segundo e a porcentagem de perdas a 5%. Do mesmo
modo, a definição do binding no repositório pode conter uma polı́tica de adaptação, com
regras que definem por exemplo, que deve ser feita uma requisição ao meta-componente
associado ao binding para substituir o componente atual de serialização por outro que faça
compressão dos pacotes de tinta.
A Figura 6 mostra a ação do gerenciador de adaptação, seguindo a polı́tica descrita
anteriormente. Na figura, o gerenciador obtém informações do ambiente de rede junto ao
monitor de contexto, verifica que existe a violação dos atributos de QoS definidos nas interfaces e busca a polı́tica de adaptação adequada para tratar essa violação no repositório
de tipos. De posse da polı́tica, o gerenciador aplica as regras acessando, através de uma interface bem conhecida, o meta-componente do binding em questão. O meta-componente
então substitui os componentes de serialização do binding.
Figure 6. Auto-adaptação.
Devido à compressão, a qualidade visual da tinta digital diminui, assim como
ocorre em outras mı́dias. Dependendo do nı́vel de compressão, a diferença em
comparação com a mı́dia original é quase imperceptı́vel pelo usuário. Diminuindo a qualidade da tinta e, conseqüentemente, o tamanho dos pacotes enviados, o fluxo de dados na
rede diminui, o que pode reduzir os efeitos do atraso e da perda de pacotes.
A compressão é apenas uma das polı́ticas que podem ser empregadas. Outras
polı́ticas podem explorar parâmetros diferentes da aplicação, como o intervalo de envio
de pacotes, que pode ser ajustado para causar uma menor carga na rede. Vale observar
que a adaptação não visa resolver os problemas do ambiente de rede, e sim modificar o
comportamento da aplicação para tentar minimizar os efeitos desses problemas. Assim,
as polı́ticas devem ser projetadas para garantir que as aplicações se comportem da melhor
forma em situações adversas.
5. Trabalhos Correlatos
A idéia de tornar uma plataforma de middleware auto-adaptativa ou auto-gerenciável não
é nova. Entre os trabalhos propostos nesta área, podemos citar [Keeney and Cahill 2003],
que propõe um framework de adaptação dinâmica de serviços baseada em mudanças no
contexto de execução. O trabalho apresenta ainda uma linguagem própria de declaração
de polı́ticas de adaptação.
Em [Grace et al. 2006], é proposta uma arquitetura para adaptação coordenada,
válida e segura de componentes. Esse trabalho segue um modelo similar ao Meta-ORB,
pois ambos foram desenvolvidos com base no modelo OpenORB [Blair et al. 2001]. Essa
arquitetura conta com um configurador distribuı́do, associado a uma máquina de contexto
e a um banco de polı́ticas.
Em contraste com estes trabalhos, em nossa arquitetura as polı́ticas de adaptação
são definidas no mesmo sistema de tipos onde as configurações das aplicações são
definidas. Assim, o desenvolvedor pode modelar a aplicação, sua infra-estrutura de
comunicação, os atributos de QoS envolvidos e as polı́ticas de adaptação com a mesma
linguagem e utilizando a mesma ferramenta. Todas essas definições podem ainda ser
reutilizadas para criar novas aplicações.
6. Conclusão
A tecnologia da tinta digital pode ser utilizada para aprimorar a interação em aplicações
colaborativas. Porém, problemas de comunicação tı́picos do ambiente computacional
dessas aplicações, como o atraso e a perda de pacotes, podem afetar a cooperação em
tempo real entre usuários. Neste artigo apresentamos uma infra-estrutura de middleware
para tratar esses problemas e desta forma manter a qualidade do canal de comunicação
nas aplicações colaborativas baseadas em tinta digital.
A arquitetura proposta pode beneficiar o desenvolvimento de aplicações colaborativas em dois pontos principais. Primeiro, o modelo de programação adotado, em conjunto com o sistema de tipos da plataforma, oferecem um modo unificado para o design da
comunicação, de QoS e das polı́ticas de adaptação da aplicação. Segundo, o middleware
oferece a infra-estrutura necessária para o gerenciamento e manutenção da qualidade da
comunicação.
Além disso, o trabalho proposto está voltado para aplicação em sistemas colaborativos baseados em tinta digital. Por se tratar de uma tecnologia relativamente nova, o
suporte de middleware para esses sistemas ainda foi pouco explorado. Assim, o desenvolvedor de aplicações desta natureza pode focar os aspectos funcionais da colaboração,
beneficiando-se da infra-estrutura de comunicação provida pelo middleware e reutilizando
configurações já existentes que tratam aspectos especı́ficos do ambiente de rede.
Os experimentos envolvidos neste trabalho foram realizados dentro de uma sala de
aula, com uma rede sem fio e dispositivos homogêneos. As informações de contexto e as
polı́ticas de adaptação apresentadas foram propostas para resolver problemas observados
nesse ambiente. Problemas de comunicação envolvidos em aplicações colaborativas para
outros ambientes de rede ainda devem ser estudados para validar melhor nossa proposta.
Assim, mesmo sistemas que envolvem multimı́dia distribuı́da em mais de um canal de
comunicação podem reutilizar e combinar configurações de middleware preexistentes.
A implementação da plataforma Meta-ORB com as extensões propostas é um trabalho ainda em andamento. Esperamos que, quando pronta, a infra-estrutura apresentada
permita que aplicações colaborativas baseadas em tinta digital sejam desenvolvidas de
forma simples e rápida, garantindo um tratamento adequado para a comunicação.
References
Anderson, R., Anderson, R., Simon, B., Wolfman, S., VanDeGrift, T., and Yasuhara, K.
(2004). Experiences with a tablet PC based lecture presentation system in computer
science courses. Proceedings of the 35th SIGCSE technical symposium on Computer
science education, pages 56–60.
Berque, D., Bonebright, T., and Whitesell, M. (2004). Using pen-based computers across
the computer science curriculum. ACM SIGCSE Bulletin, 36(1):61–65.
Berque, D., Johnson, D., and Jovanovic, L. (2001). Teaching theory of computation using
pen-based computers and an electronic whiteboard. Proceedings of the 6th annual
conference on Innovation and technology in computer science education, pages 169–
172.
Blair, G., Coulson, G., Andersen, A., Blair, L., Clarke, M., Costa, F., Duran-Limon, H.,
Fitzpatrick, T., Johnston, L., Moreira, R., et al. (2001). The Design and Implementation
of Open ORB 2. IEEE Distributed Systems Online, 2(6):1–40.
Blair, G., Coulson, G., Davies, N., Robin, P., and Fitzpatrick, T. (1997). Adaptive middleware for mobile multimedia applications. Network and Operating System Support for
Digital Audio and Video, 1997., Proceedings of the IEEE 7th International Workshop
on, pages 245–254.
Cattelan, R., Teixeira, C., Ribas, H., Munson, E., and Pimentel, M. (2008). Inkteractors:
interacting with digital ink. Proceedings of the 2008 ACM symposium on Applied
computing, pages 1246–1251.
Chiu, P., Kapuskar, A., Reitmeier, S., and Wilcox, L. (1999). NoteLook: taking notes
in meetings with digital video and ink. Proceedings of the seventh ACM international
conference on Multimedia (Part 1), pages 149–158.
Costa, F. (2002). Meta-ORB: A Highly Configurable and Adaptable Reflective Middleware Platform. Proceedings of the 20th Brazilian Symposium on Computer Networks,
pages 735–750.
Costa, F., Provensi, L., and Vaz, F. (2007). Using Runtime Models to Unify and Structure
the Handling of Meta-information in Reflective Middleware. LECTURE NOTES IN
COMPUTER SCIENCE, 4364:232.
Coulson, G. (2001). What is Reflective Middleware. IEEE Distributed Systems Online,
2(8):165–169.
Ellis, C. A., Gibbs, S. J., and Rein, G. (1991). Groupware: some issues and experiences.
Commun. ACM, 34(1):39–58.
Forman, G. and Zahorjan, J. (1994). The challenges of mobile computing. IEEE Computer, 27(4):38–47.
Fuks, H., Raposo, A., Gerosa, M., and Lucena, C. (2005). APPLYING THE 3 C MODEL
TO GROUPWARE DEVELOPMENT. International Journal of Cooperative Information Systems, 14(2):299–328.
Grace, P., Coulson, G., Blair, G., and Porter, B. (2006). A distributed architecture metamodel for self-managed middleware. Proceedings of the 5th workshop on Adaptive
and reflective middleware (ARM’06).
Hong, J. I. and Landay, J. A. (2000). Satin: a toolkit for informal ink-based applications. In UIST ’00: Proceedings of the 13th annual ACM symposium on User interface
software and technology, pages 63–72, New York, NY, USA. ACM.
Keeney, J. and Cahill, V. (2003). Chisel: a policy-driven, context-aware, dynamic adaptation framework. Policies for Distributed Systems and Networks, 2003. Proceedings.
POLICY 2003. IEEE 4th International Workshop on, pages 3–14.
Lopresti, D. (1998). Ink as Multimedia Data. Proceedings of the Fourth Intl. Conference
on Information, Systems, Analysis and Synthesis, July, pages 122–128.
Maes, P. (1987). Concepts and experiments in computational reflection. Conference on
Object Oriented Programming Systems Languages and Applications, pages 147–155.
Poon, A., Weber, K., and Cass, T. (1995). Scribbler: a tool for searching digital ink.
Conference on Human Factors in Computing Systems, pages 252–253.
Prince, M. (2004). Does Active Learning Work? A Review of the Research. Journal of
Engineering Education, 93(3):223–231.
Rieffel, E. and Toomey, L. (2007). Systems and methods for generating and controlling
temporary digital ink. US Patent 7,286,141.
Schmerl, B. and Garlan, D. (2002). Exploiting architectural design knowledge to support
self-repairing systems. Proceedings of the 14th international conference on Software
engineering and knowledge engineering, pages 241–248.
Szyperski, C. (1998). Component software: beyond object-oriented programming.