gestão de dados partilhados em ambientes de computação móvel

gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel

asc.di.fct.unl.pt
from asc.di.fct.unl.pt More from this publisher
11.04.2013 Views

62 CAPÍTULO 4. DESCRIÇÃO DAS FUNCIONALIDADES PRINCIPAIS DO SISTEMA DOORS O processamento de uma invocação é tratado como normalmente até ao momento em que é ne- cessário executar a operação na cópia privada do subobjecto. Neste momento, é criada uma cópia de substituição do subobjecto e a operação é executada sobre essa cópia, como seria executada normal- mente sobe a cópia real do subobjecto. A partir da criação desta cópia, todas as invocações seguintes são executadas nessa cópia. Os programadores, ao definirem os subobjectos, devem especificar se é possível criar cópias de substituição e o modo como estas cópias são criadas — em geral, a criação de uma cópia de substituição consiste na criação de um subobjecto em que o estado inicial é definido a partir dos parâmetros do construtor. O representante (proxy) do subobjecto contém o código necessário para criar a cópia de substituição do subobjecto 8 . Os parâmetros que definem o estado inicial da cópia de substituição podem ser definidos estaticamente, aquando da definição do código do subobjecto, ou dinamicamente, aquando da criação do subobjecto — neste caso, cada representante de um subobjecto obtém uma cópia destes parâmetros quando é criado. A aplicação, ao obter a cópia privada do coobjecto, pode especificar que não pretende criar cópias de substituição — esta opção sobrepõe-se à opção especificada na definição dos subobjectos. 4.4 Integração de sessões síncronas O sistema DOORS foi desenhado para suportar a partilha de dados em ambientes de trabalho cooperativo tipicamente assíncronos. Nestes ambientes, os utilizadores executam as suas contribuições concorrente- mente sem observarem imediatamente as modificações que os outros utilizadores estão a efectuar. Estas modificações são posteriormente unificadas através de um mecanismo de reconciliação adaptado às ca- racterísticas dos dados manipulados. Assim, é possível reconhecer duas características fundamentais: o desconhecimento das modifica- ções produzidas pelos outros utilizadores e a (significativa) dimensão das contribuições de cada utili- zador. Considere-se o exemplo da edição cooperativa de um documento. Cada utilizador desconhece as modificações que o outro está a executar, embora, em algumas situações, os utilizadores possam ter conhecimento dos elementos do documento estruturado que estão a ser modificadas pelos outros utiliza- dores — este conhecimento pode ser obtido através da informação de awareness ou coordenação formal ou informal associada à tarefa cooperativa. Adicionalmente, quando um utilizador modifica um elemento (por exemplo, uma secção), as modificações tendem a ser significativas. Num ambiente de trabalho cooperativo tipicamente assíncrono podem existir momentos pontuais em 8 No cliente, a informação sobre uma invocação contém o representante no qual a invocação foi executada. Este facto permite criar a cópia de substituição usando o código definido no representante do subobjecto, apesar de ser o componente de reconciliação que executa a operação e o gestor do subobjecto o responsável por manter as cópias dos subobjectos.

4.4. INTEGRAÇÃO DE SESSÕES SÍNCRONAS 63 que os utilizadores pretendem realizar sessões síncronas durante as quais manipulam os dados de forma síncrona. Por exemplo, durante a edição cooperativa, estas sessões síncronas podem ser usadas para coordenar o trabalho e unificar múltiplas versões dos dados. Para responder a esta necessidade, o sistema DOORS permite que os coobjectos sejam manipulados durante sessões síncronas. Para tal, é necessário manter várias cópias privadas de um coobjecto sincro- namente sincronizadas. A aproximação utilizada consiste em difundir as invocações executadas numa sessão síncrona para todas as cópias síncronas do coobjecto — um componente de adaptação especial implementa esta funcionalidade recorrendo a um mecanismo de comunicação em grupo 9 [18]. Um utilizador pode iniciar uma sessão síncrona a partir da sua cópia privada do coobjecto. Para tal, ele deve instalar o componente de adaptação síncrona no seu coobjecto (assim como um componente de reconciliação adaptado às características de uma sessão síncrona) 10 . O componente de adaptação síncrona cria um grupo para a sessão síncrona no sistema de comunicação em grupo utilizado. A partir deste momento é possível a outros utilizadores entrarem na sessão síncrona para manipular o coobjecto. Quando um utilizador pretende entrar numa sessão síncrona, a aplicação deve-se juntar ao grupo associado à sessão síncrona (no protótipo do sistema, é apenas necessário conhecer o nome da sessão e o nome de um computador que participe na sessão). A cópia privada do coobjecto é criada a partir do estado actual do coobjecto na sessão síncrona — o estado actual inclui todos os subobjectos instanciados em memória e uma referência (handle) que permite criar os subobjectos de forma coerente em todos as réplicas síncronas (no protótipo actual, o estado inicial é obtido a partir de um elemento no grupo eleito como primário). Esta cópia privada é actualizada através da execução de todas as operações difundidas na sessão síncrona e não reflectidas no estado inicial. Os elementos de uma sessão síncrona podem abandoná-la em qualquer momento que o desejem. Adi- cionalmente, o mecanismo de filiação do subsistema de comunicação em grupo pode forçar a remoção de elementos com os quais seja impossível comunicar (em situações de partição do grupo, o subsistema de comunicação em grupo apenas deve permitir que o grupo continue activo numa das partições). Em cada momento existe sempre um elemento do grupo que é designado de primário. As aplicações manipulam os coobjectos da forma habitual, i.e., através da execução de operações nos representantes dos subobjectos. As operações de leitura são executadas localmente — o componente de adaptação propaga a invocação para execução local. As operações de modificação são difundidas para 9 No protótipo do sistema DOORS foi utilizado um sistema de comunicação em grupo muito simples implementado a partir do sistema de disseminação de eventos Deeds [45], embora fosse possível ter optado por outros sistemas de comunicação em grupo — as únicas funcionalidades básicas utilizadas são a difusão de mensagens e o controlo da filiação. 10 Esta substituição de componentes representa um cenário limitado de reconfiguração dinâmica, porque as possibilidades de reconfiguração estão pré-determinadas e a arquitectura está desenhada para que esta substituição possa ser efectuada sem problemas.

4.4. INTEGRAÇÃO DE SESSÕES SÍNCRONAS 63<br />

que os utilizadores preten<strong>de</strong>m realizar sessões síncronas durante as quais manipulam os <strong>dados</strong> <strong>de</strong> forma<br />

síncrona. Por ex<strong>em</strong>plo, durante a edição cooperativa, estas sessões síncronas po<strong>de</strong>m ser usadas para<br />

coor<strong>de</strong>nar o trabalho e unificar múltiplas versões dos <strong>dados</strong>.<br />

Para respon<strong>de</strong>r a esta necessida<strong>de</strong>, o sist<strong>em</strong>a DOORS permite que os coobjectos sejam manipulados<br />

durante sessões síncronas. Para tal, é necessário manter várias cópias privadas <strong>de</strong> um coobjecto sincro-<br />

namente sincronizadas. A aproximação utilizada consiste <strong>em</strong> difundir as invocações executadas numa<br />

sessão síncrona para todas as cópias síncronas do coobjecto — um componente <strong>de</strong> adaptação especial<br />

impl<strong>em</strong>enta esta funcionalida<strong>de</strong> recorrendo a um mecanismo <strong>de</strong> comunicação <strong>em</strong> grupo 9 [18].<br />

Um utilizador po<strong>de</strong> iniciar uma sessão síncrona a partir da sua cópia privada do coobjecto. Para tal,<br />

ele <strong>de</strong>ve instalar o componente <strong>de</strong> adaptação síncrona no seu coobjecto (assim como um componente<br />

<strong>de</strong> reconciliação adaptado às características <strong>de</strong> uma sessão síncrona) 10 . O componente <strong>de</strong> adaptação<br />

síncrona cria um grupo para a sessão síncrona no sist<strong>em</strong>a <strong>de</strong> comunicação <strong>em</strong> grupo utilizado. A partir<br />

<strong>de</strong>ste momento é possível a outros utilizadores entrar<strong>em</strong> na sessão síncrona para manipular o coobjecto.<br />

Quando um utilizador preten<strong>de</strong> entrar numa sessão síncrona, a aplicação <strong>de</strong>ve-se juntar ao grupo<br />

associado à sessão síncrona (no protótipo do sist<strong>em</strong>a, é apenas necessário conhecer o nome da sessão e<br />

o nome <strong>de</strong> um computador que participe na sessão). A cópia privada do coobjecto é criada a partir do<br />

estado actual do coobjecto na sessão síncrona — o estado actual inclui todos os subobjectos instanciados<br />

<strong>em</strong> m<strong>em</strong>ória e uma referência (handle) que permite criar os subobjectos <strong>de</strong> forma coerente <strong>em</strong> todos as<br />

réplicas síncronas (no protótipo actual, o estado inicial é obtido a partir <strong>de</strong> um el<strong>em</strong>ento no grupo eleito<br />

como primário). Esta cópia privada é actualizada através da execução <strong>de</strong> todas as operações difundidas<br />

na sessão síncrona e não reflectidas no estado inicial.<br />

Os el<strong>em</strong>entos <strong>de</strong> uma sessão síncrona po<strong>de</strong>m abandoná-la <strong>em</strong> qualquer momento que o <strong>de</strong>sej<strong>em</strong>. Adi-<br />

cionalmente, o mecanismo <strong>de</strong> filiação do subsist<strong>em</strong>a <strong>de</strong> comunicação <strong>em</strong> grupo po<strong>de</strong> forçar a r<strong>em</strong>oção<br />

<strong>de</strong> el<strong>em</strong>entos com os quais seja impossível comunicar (<strong>em</strong> situações <strong>de</strong> partição do grupo, o subsist<strong>em</strong>a<br />

<strong>de</strong> comunicação <strong>em</strong> grupo apenas <strong>de</strong>ve permitir que o grupo continue activo numa das partições). Em<br />

cada momento existe s<strong>em</strong>pre um el<strong>em</strong>ento do grupo que é <strong>de</strong>signado <strong>de</strong> primário.<br />

As aplicações manipulam os coobjectos da forma habitual, i.e., através da execução <strong>de</strong> operações nos<br />

representantes dos subobjectos. As operações <strong>de</strong> leitura são executadas localmente — o componente <strong>de</strong><br />

adaptação propaga a invocação para execução local. As operações <strong>de</strong> modificação são difundidas para<br />

9 No protótipo do sist<strong>em</strong>a DOORS foi utilizado um sist<strong>em</strong>a <strong>de</strong> comunicação <strong>em</strong> grupo muito simples impl<strong>em</strong>entado a partir<br />

do sist<strong>em</strong>a <strong>de</strong> diss<strong>em</strong>inação <strong>de</strong> eventos Deeds [45], <strong>em</strong>bora fosse possível ter optado por outros sist<strong>em</strong>as <strong>de</strong> comunicação <strong>em</strong><br />

grupo — as únicas funcionalida<strong>de</strong>s básicas utilizadas são a difusão <strong>de</strong> mensagens e o controlo da filiação.<br />

10 Esta substituição <strong>de</strong> componentes representa um cenário limitado <strong>de</strong> reconfiguração dinâmica, porque as possibilida<strong>de</strong>s<br />

<strong>de</strong> reconfiguração estão pré-<strong>de</strong>terminadas e a arquitectura está <strong>de</strong>senhada para que esta substituição possa ser efectuada s<strong>em</strong><br />

probl<strong>em</strong>as.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!