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

3.2. FRAMEWORK DE COMPONENTES: PRINCÍPIOS GERAIS 29
único, uma aplicação nunca acede a um subobjecto usando directamente este identificador). Para tal, os
subobjectos podem manter referências para outros subobjectos.
Embora um coobjecto inclua instâncias de vários outros componentes, são os subobjectos que re-
presentam o valor do tipo de dados que se pretende definir — os outros componentes são usados para
controlar os vários aspectos da partilha dos dados. Assim, pode dizer-se que o estado de um coobjecto é
representado pelo estado dos subobjectos que o constituem e que reflectem a execução de uma determi-
nada sequência de operações. No entanto, de forma mais exacta, dever-se-ia considerar que o estado de
um coobjecto inclui também o estado dos outros componentes.
As aplicações e os subobjectos não mantêm referências directas para um subobjecto. Estas referên-
cias são implementadas através de representantes de subobjectos (proxies) que implementam a mesma
interface dos subobjectos. O uso de representantes elimina a necessidade de interceptar as invocações de
métodos num subobjecto ao nível do sistema de execução dos programas.
Os representantes (proxies) permitem executar de forma simples as seguintes funcionalidades ne-
cessárias ao funcionamento do sistema DOORS. Primeiro, os representantes permitem interceptar as
invocações de métodos de um subobjecto e criar o necessário registo de invocações (esta características
é fundamental num sistema de replicação baseado na propagação das modificações como sequências de
operações). Segundo, os representantes permitem que apenas se instanciem os subobjectos quando é
necessário executar métodos desses subobjectos. Terceiro, os representantes eliminam a necessidade de
modificar os apontadores usados para referenciar outros subobjectos quando um subobjecto é instanci-
ado 4 . Quarto, os representantes encapsulam os identificadores dos subobjectos, os quais não são visíveis
pelas aplicações — o acesso aos subobjectos efectua-se sempre por navegação (a partir de um objecto
base), como é normal nas linguagens orientadas para os objectos.
A instanciação de um subobjecto é executada pelo gestor de subobjectos (cluster manager) apenas
quando necessário. O gestor de subobjectos mantém referências para todos os subobjectos presentes em
memória de forma a garantir que apenas existe uma instância de cada subobjecto.
Adicionalmente, o gestor dos subobjectos é responsável por manter referências para o subobjecto
base (ou conjunto de subobjectos base) — por exemplo, no documento estruturado, a estrutura principal
do documento é o subobjecto base, o qual permite aceder aos outros subobjectos por navegação na
estrutura do documento. Todos os outros subobjectos são acedidos a partir destes por navegação. O
gestor dos subobjectos é ainda responsável por controlar a persistência dos subobjectos em cada um dos
servidores.
4 Nas bases de dados orientadas para os objectos, este processo chama-se pointer swizzling [171]