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
84 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS n_seq identifica univocamente a sequência de operações no conjunto das sequências de operações recebi- das nesse servidor. Com base nestes identificadores, cada coobjecto mantém um sumário (vector versão) das operações conhecidas localmente, um sumário (vector versão) das operações executadas localmente, e um sumário (vector versão ou matriz) das operações que se sabe serem conhecidas nas outras réplicas. Estes sumários são actualizados durante as sessões de sincronização e aquando da recepção e execução das operações. O sumário das operações executadas localmente (conjuntamente com o identificador da vista no qual ele é válido) chama-se versão do coobjecto. 6.1.6 Sistema de nomes A camada de designação simbólica permite às aplicações usar nomes simbólicos para se referirem aos volumes e aos coobjectos. Assim, esta camada define um conjunto de funções que permitem manipular os volumes e os coobjectos usando nomes simbólicos. Estas funções convertem os nomes simbólicos nos identificadores únicos usados pelo sistema e invocam as operações respectivas na API do sistema. O nome simbólico de um coobjecto tem a seguinte forma: [//servidor][/volume :]nome, com servidor o nome do servidor em que o nome deve ser resolvido, volume o nome do volume e nome o nome do coobjecto que se pretende designar. Cada volume possui um identificador único gerado automaticamente aquando da sua criação e um nome simbólico especificado pelo utilizador. Quando se usa um nome simbólico para identificar um volume, o nome é resolvido no servidor indicado. Caso o servidor não seja indicado, o nome é resolvido localmente. Ocorre um erro caso não se conheça nenhum volume com o nome indicado ou se existir mais do que um volume com esse nome. Nestes casos, a aplicação deve usar uma função do sistema (listVolumeIds) para obter a lista de identificadores de volumes com um dado nome — o resultado desta operação não é necessariamente completo (a execução da operação recorre ao serviço de descoberta que se apresenta na secção 6.2.3). Os identificadores dos volumes são expostos como cadeias de caracteres compostas pelo nome simbólico e por uma representação do identificador único. Estes identificadores podem ser usados para designar um volume de forma única. Cada volume define um espaço hierárquico de nomes (semelhante ao espaço de nomes definido num sistema de ficheiros), em que cada nome é associado a um identificador único de um coobjecto. Esta associação é mantida no coobjecto directório global, idêntico ao descrito na secção 3.3.10 3 Este coobjecto tem um identificador único bem-definido no volume (igual para todos os volumes). Quando um coobjecto é gravado pela primeira vez, a camada de designação adiciona ao directório 3 Relativamente à descrição da secção 3.3.10, este coobjecto permite a definição adicional de ligações simbólicas (symbolic links) através de um subobjecto criado para o efeito.
6.2. SERVIDORES 85 global a associação entre o nome atribuído pela aplicação e o identificador único do coobjecto. A in- terpretação de um nome simbólico é efectuada obtendo, no coobjecto directório global, o identificador único associado a esse nome. Quando se executa a função da API do sistema (definida na camada de designação) para remover um coobjecto, remove-se adicionalmente a associação entre o nome e o identificador desse coobjecto (submetendo a operação de remoção respectiva no directório global). Quando um coobjecto removido é “ressuscitado” pela existência de operações concorrentes com a operação de remoção, é criada uma nova associação entre um nome pertencente a um directório especial e o identificador único do coobjecto. A adição do novo nome é submetida apenas no servidor que recebeu a operação de remoção do coobjecto. Esta responsabilidade é delegada (no patrocinador) no caso de o servidor cessar a replicação do volume. 6.2 Servidores Os servidores replicam volumes de coobjectos usando uma estratégia optimista. Esta aproximação per- mite fornecer aos clientes um elevada disponibilidade dos dados para operações de leitura e escrita, permitindo mascarar (algumas) falhas nos servidores e no sistema de comunicações. Um servidor é responsável por gerir a cópia local de cada volume, incluindo uma cópia de cada coobjecto contido no volume replicado. Os servidores comunicam entre si para sincronizar o estado das réplicas locais. Adicionalmente, os servidores fornecem uma interface para administrar o servidor e aceder aos coobjectos. Assim, os utilizadores (administradores do sistema) podem criar novos volumes e gerir o conjunto de servidores que replicam cada volume. Para tal, os utilizadores submetem as operações que desejam efectuar num cliente que as propaga para o(s) servidor(es) apropriado(s). Os clientes podem ainda obter cópias de coobjectos e submeter operações de modificação (em consequência das acções executadas pelos utilizadores). Nesta secção descreve-se o funcionamento do servidor, incluindo os vários protocolos executados no protótipo do sistema DOORS. 6.2.1 Volumes e filiação Um volume é um contentor de coobjectos replicado por um grupo variável de servidores. Um volume é criado num servidor em resultado de uma operação (createVolume) submetida por um utilizador (admi- nistrador do sistema). Um servidor inicia ou cessa a replicação de um volume em resultado de operações (replicateVolume e unreplicateVolume respectivamente) submetidas pelos utilizadores. Estas operações levam à execução de protocolos de inserção/remoção de um servidor no grupo de replicadores de um volume. Estes protocolos são iniciados pelo servidor que inicia/cessa a replicação do volume e têm a participação de apenas um outro servidor, que se designa de patrocinador.
- 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 and 80: 4.3. INVOCAÇÃO CEGA 61 4.3 Invoca
- Page 81 and 82: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- 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: 6.1. COOBJECTOS 83 o mesmo estado i
- 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
- Page 131 and 132: 7.3. TRANSACÇÕES MÓVEIS 113 abor
- Page 133 and 134: Capítulo 8 Reservas Neste capítul
- Page 135 and 136: 8.1. TIPOS DE RESERVAS 117 8.1.4 Re
- Page 137 and 138: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 139 and 140: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 141 and 142: 8.3. PROCESSAMENTO DAS TRANSACÇÕE
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145 and 146: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 147 and 148: 8.5. EXEMPLOS 129 1 ------ COMPRA 1
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
6.2. SERVIDORES 85<br />
global a associação entre o nome atribuído pela aplicação e o i<strong>de</strong>ntificador único do coobjecto. A in-<br />
terpretação <strong>de</strong> um nome simbólico é efectuada obtendo, no coobjecto directório global, o i<strong>de</strong>ntificador<br />
único associado a esse nome.<br />
Quando se executa a função da API do sist<strong>em</strong>a (<strong>de</strong>finida na camada <strong>de</strong> <strong>de</strong>signação) para r<strong>em</strong>over<br />
um coobjecto, r<strong>em</strong>ove-se adicionalmente a associação entre o nome e o i<strong>de</strong>ntificador <strong>de</strong>sse coobjecto<br />
(submetendo a operação <strong>de</strong> r<strong>em</strong>oção respectiva no directório global). Quando um coobjecto r<strong>em</strong>ovido é<br />
“ressuscitado” pela existência <strong>de</strong> operações concorrentes com a operação <strong>de</strong> r<strong>em</strong>oção, é criada uma nova<br />
associação entre um nome pertencente a um directório especial e o i<strong>de</strong>ntificador único do coobjecto. A<br />
adição do novo nome é submetida apenas no servidor que recebeu a operação <strong>de</strong> r<strong>em</strong>oção do coobjecto.<br />
Esta responsabilida<strong>de</strong> é <strong>de</strong>legada (no patrocinador) no caso <strong>de</strong> o servidor cessar a replicação do volume.<br />
6.2 Servidores<br />
Os servidores replicam volumes <strong>de</strong> coobjectos usando uma estratégia optimista. Esta aproximação per-<br />
mite fornecer aos clientes um elevada disponibilida<strong>de</strong> dos <strong>dados</strong> para operações <strong>de</strong> leitura e escrita,<br />
permitindo mascarar (algumas) falhas nos servidores e no sist<strong>em</strong>a <strong>de</strong> comunicações.<br />
Um servidor é responsável por gerir a cópia local <strong>de</strong> cada volume, incluindo uma cópia <strong>de</strong> cada<br />
coobjecto contido no volume replicado. Os servidores comunicam entre si para sincronizar o estado<br />
das réplicas locais. Adicionalmente, os servidores fornec<strong>em</strong> uma interface para administrar o servidor e<br />
ace<strong>de</strong>r aos coobjectos. Assim, os utilizadores (administradores do sist<strong>em</strong>a) po<strong>de</strong>m criar novos volumes e<br />
gerir o conjunto <strong>de</strong> servidores que replicam cada volume. Para tal, os utilizadores submet<strong>em</strong> as operações<br />
que <strong>de</strong>sejam efectuar num cliente que as propaga para o(s) servidor(es) apropriado(s). Os clientes po<strong>de</strong>m<br />
ainda obter cópias <strong>de</strong> coobjectos e submeter operações <strong>de</strong> modificação (<strong>em</strong> consequência das acções<br />
executadas pelos utilizadores). Nesta secção <strong>de</strong>screve-se o funcionamento do servidor, incluindo os<br />
vários protocolos executados no protótipo do sist<strong>em</strong>a DOORS.<br />
6.2.1 Volumes e filiação<br />
Um volume é um contentor <strong>de</strong> coobjectos replicado por um grupo variável <strong>de</strong> servidores. Um volume é<br />
criado num servidor <strong>em</strong> resultado <strong>de</strong> uma operação (createVolume) submetida por um utilizador (admi-<br />
nistrador do sist<strong>em</strong>a). Um servidor inicia ou cessa a replicação <strong>de</strong> um volume <strong>em</strong> resultado <strong>de</strong> operações<br />
(replicateVolume e unreplicateVolume respectivamente) submetidas pelos utilizadores. Estas operações<br />
levam à execução <strong>de</strong> protocolos <strong>de</strong> inserção/r<strong>em</strong>oção <strong>de</strong> um servidor no grupo <strong>de</strong> replicadores <strong>de</strong> um<br />
volume. Estes protocolos são iniciados pelo servidor que inicia/cessa a replicação do volume e têm a<br />
participação <strong>de</strong> apenas um outro servidor, que se <strong>de</strong>signa <strong>de</strong> patrocinador.