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
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.
- Page 29 and 30: 2.2. MOTIVAÇÃO - ALGUMAS APLICAÇ
- Page 31 and 32: 2.3. PRINCÍPIOS 13 garantir a disp
- Page 33 and 34: 2.3. PRINCÍPIOS 15 obter o estado
- Page 35 and 36: 2.3. PRINCÍPIOS 17 sobre a evoluç
- Page 37 and 38: 2.3. PRINCÍPIOS 19 2.3.6 Invocaç
- Page 39 and 40: 2.3. PRINCÍPIOS 21 solúveis). As
- Page 41 and 42: Capítulo 3 Apresentação do siste
- Page 43 and 44: 3.1. MODELO GERAL 25 para a activid
- Page 45 and 46: 3.1. MODELO GERAL 27 Aplicação At
- Page 47 and 48: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 49 and 50: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 51 and 52: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 53 and 54: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 55 and 56: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 57 and 58: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 59 and 60: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 61 and 62: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 63 and 64: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 65 and 66: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 67 and 68: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 69 and 70: Capítulo 4 Descrição das funcion
- Page 71 and 72: 4.1. RECONCILIAÇÃO 53 Segundo, um
- Page 73 and 74: 4.1. RECONCILIAÇÃO 55 4.1.3 Ordem
- Page 75 and 76: 4.1. RECONCILIAÇÃO 57 4.1.4.2 Ver
- Page 77 and 78: 4.1. RECONCILIAÇÃO 59 No decurso
- Page 79: 4.3. INVOCAÇÃO CEGA 61 4.3 Invoca
- Page 83 and 84: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 85 and 86: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 87 and 88: Capítulo 5 Avaliação do modelo d
- Page 89 and 90: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 91 and 92: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 93 and 94: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 95 and 96: 5.2. AGENDA PARTILHADA 77 Figura 5.
- Page 97 and 98: 5.2. AGENDA PARTILHADA 79 de awaren
- Page 99 and 100: Capítulo 6 Núcleo do sistema DOOR
- Page 101 and 102: 6.1. COOBJECTOS 83 o mesmo estado i
- Page 103 and 104: 6.2. SERVIDORES 85 global a associa
- Page 105 and 106: 6.2. SERVIDORES 87 segundo servidor
- Page 107 and 108: 6.2. SERVIDORES 89 6.2.2 Sincroniza
- Page 109 and 110: 6.2. SERVIDORES 91 6.2.3 Serviço d
- Page 111 and 112: 6.2. SERVIDORES 93 ao cliente compl
- Page 113 and 114: 6.2. SERVIDORES 95 • Emulação d
- Page 115 and 116: 6.3. CLIENTES 97 do coobjecto consi
- Page 117 and 118: 6.3. CLIENTES 99 seguinte informaç
- Page 119 and 120: 6.3. CLIENTES 101 A propagação as
- Page 121 and 122: Capítulo 7 Apresentação do siste
- Page 123 and 124: 7.1. MODELO GERAL 105 encomenda de
- Page 125 and 126: 7.2. ARQUITECTURA 107 BD réplica C
- Page 127 and 128: 7.2. ARQUITECTURA 109 O subsistema
- Page 129 and 130: 7.3. TRANSACÇÕES MÓVEIS 111 7.3
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.