Requisitos de Projeto

As opções de projeto para oferecer controle de palavra são inúmeras. Entretanto, as necessidades de utilização dos diferentes recursos podem ser úteis para restringir o número de caminhos de implementação.

Uma premissa do projeto é emular o mundo real do dia-a-dia num ambiente virtual colaborativo. Enquanto certas qualidades do ambiente real são intangíveis, novas características dos ambientes virtuais podem ser exploradas como, por exemplo, a combinação de várias tarefas numa

única sessão de trabalho. Atualmente, a maioria dos softwares colaborativos [02] é específica e dedicada a determinados tipos de tarefas e sem um controle de palavra muito sofisticado.

Os sistemas colaborativos vêm tornando-se cada vez mais polimorfos em relação à variedade de recursos que podem ser usados ao mesmo tempo. A Tabela 7, baseada em [02], classifica as aplicações típicas de acordo com os tipos genéricos de dados e tarefas e mostra a importância de requisitos de QoS e Controle de palavra. Os campos marcados com “x” indicam que o critério correspondente que se aplica:

− Trabalha com recursos temporários (T) ou se resulta em dados persistentes;

− É possível aplicar à colaboração síncrona (S);

− São recursos que necessitam de envio de dados tempo real (RT) e são sensíveis a atrasos;

− Toleram perdas (L) ou são sujeitos ao jitter (J);

− Requerem alta (H), média (M) ou baixa (L) largura de banda (BW).

A última coluna indica a dimensão da palavra (FD), ou seja, o tipo de conflito no domínio temporal (t), espacial (s), ou funcional (f) que o controle de palavra normalmente precisa resolver no trabalho colaborativo para um recurso específico [02]:

− Compartilhamento temporal indica possibilidade de conflitos causais ou temporais, por exemplo, o revezamento de dois participantes numa conversa;

− Conflitos de compartilhamento espacial surgem do uso da mesma área de apresentação ou espaço de armazenamento de uma área de trabalho compartilhada;

− Compartilhamento funcional se concentra em torno do uso das mesmas funções da aplicação que alternam o status ou conteúdo de um recurso compartilhado, por exemplo, a função para apagar arquivos de texto.

Tipo T S RT L J BW FD Texto Editor Chat E-mail Agenda X X X X L L L L t,s,f t t,f t,s Áudio X X X X X M t,f Imagens e Vídeo Estático Em movimento X X X X X X M,H H s,f t,f Gráficos Estático Em movimento X X X X M M,H t,s,f t,s,f WWW X X L-H t,s,f Realidade Virtual X X X X H t,s,f

Tabela 7: Tipos de recursos e características de manipulação

Do ponto de vista da rede, pode-se identificar, basicamente, quatro classes de tráfego multimídia [02], as quais impõem diferentes requisitos de QoS ao ACM:

− Pacotes de controle (control packets) para controle de palavra e de sessão que, geralmente, consistem em pequenas quantidades de dados a serem transmitidos, mas que necessitam transmissão confiável;

− Pacotes tempo real (real-time data) para as mídias com requisitos temporais, que possivelmente suportam determinada taxa de perdas;

− Pacotes de dados não tempo real (non real-time data) para aplicações que possuem requisitos temporais não rígidos, e;

− Transferências de volumes de dados (bulky data-transfers) que normalmente acontecem nos momentos de replicação, re- sincronização que geralmente ocorrem no início, recuperação e finalização de uma sessão. Esta classe de transferências necessita de alta largura de banda e transmissão confiável, mas toleram certo nível de atraso.

Assim, devido à magnitude dos tipos de recursos, dos cenários de sessões e condições de redes, é necessário que o controle de palavra seja realizado através de uma arquitetura de coordenação que contemple os diferentes tipos de serviços necessários [02]. Então, para realizar o melhor serviço possível num ACM, considerando estes aspectos, deve-se favorecer decisões de projeto que permitam requisitos fundamentais [03] para a arquitetura de coordenação, e conseqüentemente para o controle de palavra, como:

− Simplicidade de implementação e manutenção;

− Escalabilidade em termos do número de usuários e hosts; − Segurança em relação à troca de dados e informações de

coordenação;

− Extensibilidade para novos recursos e modelos de sessões; − Eficiência da coordenação em relação à baixa latência e

overhead do protocolo;

− Confiabilidade em relação à falhas em hosts, recursos e elementos de rede;

− Persistência das informações da coordenação nos hosts não obstante a natureza efêmera dos sinais de coordenação, e; − Interoperabilidade entre plataformas heterogêneas.

Em trabalho colaborativo, não faz sentido separar a capacidade de distribuição do sistema, da necessidade do usuário relativo a estas interações. Assim, considerando os requisitos fundamentais, dentre as decisões de projeto [02] da arquitetura de coordenação devem estar:

1. Distribuição das informações de estado armazenadas para permitir a escalabilidade, melhor desempenho a respeito de concessão de palavra via conexões multipontos, e resiliência. Esta permite sessões tolerantes à falhas para o caso de sítios ou enlaces falharem e seccionarem a rede. O modelo com um servidor de palavra centralizado poderia ser um gargalo para o desempenho e configurar um ponto único de falha;

2. Assimetria das interações para permitir que cada sítio proceda independentemente com seu trabalho local e entre na sessão com seu conjunto de recursos que lhe são peculiares, quando desejar. Os recursos podem, por isso, ser heterogêneos, e comutar suavemente entre trabalho colaborativo síncrono e assíncrono durante interações em uma sessão ao vivo;

3. Hierarquia no gerenciamento de sessão reflete a dinâmica dos encontros presenciais. Ela permite a reconfiguração da sessão criando subgrupos sem a necessidade de se separar ou sair da sessão principal.

4. Adaptação com relação a recursos, firmeza (tighness) no controle do espaço compartilhado, e atendimento das requisições, baseado num QoS desejado x possível, permitem que as aplicações se ajustem às expectativas do usuário e a configuração do ACM. A Adaptação também considera os requisitos de planejamento de vários recursos, por exemplo,

deadlines do tipo hard ou soft para mídias dependentes de

requisitos temporais.