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
96 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS //------------------ GESTÃO DE VOLUMES : ADMINISTRADORES --------------------------------- // Cria novo volume void createVolume( String inServer, String volumeName); // Inicia/cassa replicação do volume indicado void replicateVolume( String inServer, String volumeName, MbrshipElement fromServer); void unreplicateVolume( String inServer, String volumeName); // Força sincronização do volume/coobjecto indicado void synchronizeVolume( String inServer, String volumeName, String fromServer); void synchronizeObject( String inServer, CoobjId id, String fromServer) // Lista volumes replicados num servidor String[] listVolumes( String server); // Lista identificadores de volumes com um dado nome String[] listVolumeIds( String volumeName, int wait); //------------------ ACESSO AOS COOBJECTOS : UTILIZADORES -------------------------------- // Lê um coobjecto existente public CoObject getCoObject( CoobjId id, int flags); public CoObject getCoObject( CoobjId id, CachePolicy policy, int flags); // "Grava" as modificações efectuadas no coobjecto public void putCoObject( CoObject proxy); // Armazena o coobjecto dado no sistema com o nome "id" public void putCoObject( CoObject proxy, CoobjId id); // Remove o coobjecto "id" public void deleteCoObject( CoobjId id); // Lê/grava atributos de um coobjecto existente public CoObjectAttrib getCoObjectAttrib( CoobjId id, int flags); void putCoObjectAttrib( CoObjectAttrib attrib); //sistema Figura 6.3: API do sistema DOORS. Assincronamente, o serviço de awareness usa o serviço de descoberta para procurar outros servidores que saibam propagar a mensagem usando o método solicitado pelo coobjecto. Se possível, o servidor importa o código e as definições necessárias para processar localmente as mensagens. Caso tal não seja possível, o servidor propaga as mensagens para serem processadas noutro servidor. 6.3 Clientes Os clientes do sistema DOORS fornecem às aplicações uma interface que lhes permite aceder aos coob- jectos e administrar os servidores — ver figura 6.3. Para fornecerem estes serviços, os clientes acedem às operações disponibilizadas pelos servidores descritas na secção 6.2.4. Adicionalmente, para permitir o acesso aos dados em situações de desconexão, os clientes mantêm cópias parciais dos coobjectos. O modo de funcionamento do cliente é detalhado nesta secção. 6.3.1 Replicação secundária parcial Os clientes mantêm cópias parciais dos coobjectos. Uma cópia parcial de um coobjecto consiste na parte comum do coobjecto e num subconjunto dos subobjectos contidos no coobjecto. A parte comum
6.3. CLIENTES 97 do coobjecto consiste nos componentes necessários (cápsula, atributos do sistema, etc.) à criação de uma cópia do coobjecto. De forma semelhante ao servidor, para cada coobjecto/subobjecto replicado localmente, o cliente mantém um conjunto de recursos no qual está armazenado o seu estado actual. Os clientes obtém as cópias parciais a partir de um qualquer servidor. Com cada cópia de um coob- jecto (e respectivos subobjectos), o cliente mantém o identificador da vista no servidor quando a cópia foi obtida. Este identificador da vista é usado em todas as interacções com os servidores para que estes possam interpretar correctamente os identificadores das operações (e vectores versão). Actualização da cópia parcial de um coobjecto Uma cópia parcial de um coobjecto pode ser actuali- zada a partir de qualquer servidor. Se o servidor tem instalada uma vista diferente da vista usada na cópia do cliente, o cliente deve contactar um novo servidor ou obter uma cópia nova a partir deste servidor. Para determinar se a cópia de um cliente necessita de ser actualizada, o servidor compara a versão do coobjecto da sua cópia local, o.v, e a versão do coobjecto que o cliente possui, rv. Se os dois vectores forem iguais (o.v[i] = rv[i],∀i), a cópia do cliente está actualizada. Se o vector do servidor for superior ao do cliente, i.e., o.v[i] ≥ rv[i],∀i, o servidor tem uma versão mais recente e a versão do cliente pode ser actualizada. Se o vector do servidor for inferior ao do cliente, i.e., o.v[i] ≤ rv[i],∀i, o servidor tem uma versão mais antiga do que a versão do cliente (obtida a partir de outro servidor) — neste caso, o cliente tem a opção de obter a cópia mais antiga (o comportamento desejado é especificado como parâmetro da operação getCoOb ject). Se nenhuma das situações anteriores se verificar, o cliente e o servidor possuem versões concorrentes do coobjecto (cada uma reflecte operações que a outra não reflecte) — neste caso, a versão do cliente não pode ser actualizada, mas o cliente pode obter uma nova cópia. Quando a cópia parcial de um cliente é actualizada, o servidor pode enviar para o cliente uma nova cópia do estado do coobjecto (incluindo todos os subobjectos modificados nos quais o cliente está inte- ressado) ou uma sequência de operações a executar no cliente para actualizar a cópia local. Quando se usa esta segunda opção, o cliente executa a sequência de operações recebidas pela ordem indicada. Se ocorrer algum erro durante a execução das operações no cliente (por exemplo, devido ao facto de não existir uma cópia local de um subobjecto usado), o cliente obtém uma nova cópia do estado do coobjecto. A actualização dum coobjecto deve incluir a actualização de todos os subobjectos contidos na cópia parcial do cliente – caso contrário, a cópia local ficaria inconsistente. Quando a actualização da cópia de um coobjecto no cliente é efectuada através da propagação do estado do coobjecto, o servidor verifica a necessidade de enviar uma nova cópia de um subobjecto. Esta verificação é efectuada determinando se alguma operação que ainda não está reflectida na cópia do cliente modificou o subobjecto considerado, i.e, se ∃i : so.v[i] > rv[i], com so.v o sumário das operações que modificaram o subobjecto e rv a versão do coobjecto no cliente (note-se que podem ter sido executadas novas operações no servidor que não tenham modificado o subobjecto). Neste caso, o servidor envia uma nova cópia do subobjecto.
- 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 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: 6.2. SERVIDORES 95 • Emulação d
- 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
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
- Page 155 and 156: 9.2. RESERVAS 137 seguinte forma. P
- Page 157 and 158: 9.2. RESERVAS 139 Commit (% total)
- Page 159 and 160: 9.2. RESERVAS 141 Commit (% total)
- Page 161 and 162: 9.2. RESERVAS 143 Commit (% total)
- Page 163 and 164: 9.2. RESERVAS 145 Commit (% total)
96 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS<br />
//------------------ GESTÃO DE VOLUMES : ADMINISTRADORES ---------------------------------<br />
// Cria novo volume<br />
void createVolume( String inServer, String volumeName);<br />
// Inicia/cassa replicação do volume indicado<br />
void replicateVolume( String inServer, String volumeName, MbrshipEl<strong>em</strong>ent fromServer);<br />
void unreplicateVolume( String inServer, String volumeName);<br />
// Força sincronização do volume/coobjecto indicado<br />
void synchronizeVolume( String inServer, String volumeName, String fromServer);<br />
void synchronizeObject( String inServer, CoobjId id, String fromServer)<br />
// Lista volumes replicados num servidor<br />
String[] listVolumes( String server);<br />
// Lista i<strong>de</strong>ntificadores <strong>de</strong> volumes com um dado nome<br />
String[] listVolumeIds( String volumeName, int wait);<br />
//------------------ ACESSO AOS COOBJECTOS : UTILIZADORES --------------------------------<br />
// Lê um coobjecto existente<br />
public CoObject getCoObject( CoobjId id, int flags);<br />
public CoObject getCoObject( CoobjId id, CachePolicy policy, int flags);<br />
// "Grava" as modificações efectuadas no coobjecto<br />
public void putCoObject( CoObject proxy);<br />
// Armazena o coobjecto dado no sist<strong>em</strong>a com o nome "id"<br />
public void putCoObject( CoObject proxy, CoobjId id);<br />
// R<strong>em</strong>ove o coobjecto "id"<br />
public void <strong>de</strong>leteCoObject( CoobjId id);<br />
// Lê/grava atributos <strong>de</strong> um coobjecto existente<br />
public CoObjectAttrib getCoObjectAttrib( CoobjId id, int flags);<br />
void putCoObjectAttrib( CoObjectAttrib attrib); //sist<strong>em</strong>a<br />
Figura 6.3: API do sist<strong>em</strong>a DOORS.<br />
Assincronamente, o serviço <strong>de</strong> awareness usa o serviço <strong>de</strong> <strong>de</strong>scoberta para procurar outros servidores<br />
que saibam propagar a mensag<strong>em</strong> usando o método solicitado pelo coobjecto. Se possível, o servidor<br />
importa o código e as <strong>de</strong>finições necessárias para processar localmente as mensagens. Caso tal não seja<br />
possível, o servidor propaga as mensagens para ser<strong>em</strong> processadas noutro servidor.<br />
6.3 Clientes<br />
Os clientes do sist<strong>em</strong>a DOORS fornec<strong>em</strong> às aplicações uma interface que lhes permite ace<strong>de</strong>r aos coob-<br />
jectos e administrar os servidores — ver figura 6.3. Para fornecer<strong>em</strong> estes serviços, os clientes ace<strong>de</strong>m<br />
às operações disponibilizadas pelos servidores <strong>de</strong>scritas na secção 6.2.4. Adicionalmente, para permitir<br />
o acesso aos <strong>dados</strong> <strong>em</strong> situações <strong>de</strong> <strong>de</strong>sconexão, os clientes mantêm cópias parciais dos coobjectos. O<br />
modo <strong>de</strong> funcionamento do cliente é <strong>de</strong>talhado nesta secção.<br />
6.3.1 Replicação secundária parcial<br />
Os clientes mantêm cópias parciais dos coobjectos. Uma cópia parcial <strong>de</strong> um coobjecto consiste na<br />
parte comum do coobjecto e num subconjunto dos subobjectos contidos no coobjecto. A parte comum