Notas de Aula - MAC 5759 - Sistemas de Objetos Distribuídos

Aula 16 - 14/5/2002

Serviço de Objetos Persistentes

• Inicialmente, o OMG definiu o Persistent Object Service que era um serviço cujo objetivo era dar suporte à implementação de objetos persistentes.
• No entanto, depois que o serviço foi utilizado, notou-se que ele era muito complicado e difícil de usar.
• Esta pequena tese de mestrado descreve o serviço e algumas experiências com ele.
• Decidiu-se então mudar a abordagem e definiu-se o Persistent State Service.

Serviço de Estado Persistente (PSS)

• Já estudamos anteriormente referências persistentes para objetos. Agora, estudaremos objetos cujo estado é persistente.
• Em outras palavras, o tempo de vida do estado do objeto persiste de uma ativação para outra do objeto; o tempo de vida do estado do objeto transcende a vida do processo no qual o objeto está inserido.
• Estado persistente e referências persistentes não necessariamente andam juntos; podemos ter um e não ter o outro.
• Mas, em geral, andam juntos.

• É um serviço para os programadores de serventes, é totalmente transparente para os clientes.
• O PSS poderia ser visto como uma interface OO para um gerenciador de banco de dados orientado a objetos (OODBMS).
• Mas, na verdade, para simplificar, o PSS deixou de fora transações e consultas (queries).
• Em Java, podemos tornar o estado persistente usando seriação.
• Em Java, podemos acessar bancos de dados SQL através de JDBC.
• JDBC oferece mais poder (inclui transações e consultas) mas poder de abstração mais limitado (sua linguagem de definição de dados (DDL) é limitada ao modelo não orientado a objetos de SQL).
• O PSS usa uma Linguagem de Definição de Estado Persistente (PSDL) orientada a objetos.
• Existem mapeamentos de PSDL para BDs SQL, BDs OO e para arquivos comuns.
• Em particular, JDBC pode ser usado para implementar o PSS.
  

Conceitos Básicos do PSS

• É o único serviço de CORBA que se mete na parte de dentro dos objetos.
• Em geral, serviços CORBA só estão interessados na interface exterior.
• Como a definição de interfaces não diz nada sobre o estado interno do objeto, foi necessário desenvolver uma Linguagem de Definição de Estado Persistente (PSDL), um super-conjunto de IDL.
• Um compilador de PSDL transforma as especificações em código para lidar com BDs ou arquivos.
  
• Principais conceitos:
• Datastore
• é o mecanismo de armazenamento (BD, arquivos, etc.)
• Storage Homes
• são partições do datastore onde os storage objects são armazenados
• aparecem dentro do datastore e dentro de catálogos (no processo do servente)
• possuem um tipo definido em PSDL
  
• Storage Objects (objetos de armazenamento)
• os dados em si, equivalentes a tuplas ou linhas em bancos de dados
• possuem um tipo (storagetype) definido estaticamente em PSDL
• short-pid define um objeto de armazenamento unicamente dentro de um home
• pid define um objeto de armazenamento unicamente globalmente
• essas identificações não são IORs
  
• Catalogs
  

• Três restrições importantes:
1. Só pode haver 1 storage home de um determinado tipo dentro de um datastore
2. Storage homes contém storage objects de um único tipo
3. Para cada tipo de storage object só pode haver um storage home dentro de cada datastore
• No processo do servente, temos instâncias dos objetos de armazenamento. Podem estar em dois estados:
1. conectado: é chamado de encarnação do objeto de armazenamento; mudanças no primeiro são transmitidas para o segundo
2. desconectado: mudanças no primeiro não são refletidas no segundo
• Passos para um servente acessar um objeto persistente:
• estabelecer uma Sessão (que pode ser transacional ou não)
• a Sessão, uma conexão lógica entre o processo do servente e o datastore cria um Catálogo
• a partir do catálogo, o servente pode criar instâncias do Storage Home
• essas instâncias contém os storage objects
  

• Para modificar um servidor CORBA para tornar seu estado persistente o programador precisa:
• Escrever definições PSDL para os Storage Homes  e para o storagetype (p/ os objetos)
• Implementar operações nos objetos de armazenamento e Storage Homes, se necessário

• Exemplo:
• // Pessoas.psdl
  abstract storagetype Pessoa {
      readonly state long RG;
      state string nome;
      state string telefone;
      state ref<Pessoa> conjuge;
      void casamenton (in ref<Pessoa> o_conjuge);
  };
  abstract storagehome PessoaHome of Pessoa {
      factory create(in long RG, in string nome,
                     in string telefone);
  };
  
  catalog Pessoas {
     provides PessoaHome pessoa_home;
  };
  
  
• Como localizar um conector para o PSS,  criar uma sessão e um objeto persistente:
• import org.omg.*;
  CORBA.ORB myOrb = CORBA.ORB.init();
  CosPersistentState.ConnectorRegistry connectorRegistry =
    CosPersistentState.ConnectorRegistryHelper.narrow(
          myOrb.resolve_initial_references("PSS") );
  CosPersistentState.Connector connector = connectorRegistry.find_connector(""); // cria sessão básica (sem transações)
  CosPersistentState.Session mySession =
            connector.create_basic_session(org.omg.CosPersistentState.READ_WRITE,
             ""  , parameters );
  // acha a home de Pessoa
  // (pessoaHome is a storage home instance)
  PessoaHome pessoaHome = (PessoaHome) mySession.find_storage_home
      ("PSDL:PessoaHomeImpl:1.0");
  // cria joao
  Pessoa joao = pessoaHome.create(18044128, "J.J. da Silva", "(0xx11)9649-9000");
  
  
• Todos os storagetypes herdam implicitamente da interface CosPersistentState::StorageObject:
  
  • module CosPersistentState {
      // ...
      native StorageObjectBase;
  
      abstract storagetype StorageObject {
          void destroy_object();
          boolean object_exists();
          Pid get_pid();
          ShortPid get_short_pid();
          StorageHomeBase get_storage_home();
      };
  };
  
  
• As operações seguintes se aplicam a qualquer objeto de armazenamento:
  destroy_object() destroi o objeto. 
  object_exists() devolve verdadeiro se a incarnação realmente está associada a um objeto no datastore. 
  get_pid e get_short_pid devolve os identificadores do objeto. 
  get_storage_home() devolve o home que gerencia esse objeto. 
  
  
• Todas as instâncias de storage homes herdam de CosPersistentState::StorageHomeBase :
• module CosPersistentState {
      exception NotFound {};
      native StorageObjectBase
      // ...
      local interface StorageHomeBase
          StorageObjectBase
            find_by_short_pid(in ShortPid short_pid)
                 raises (NotFound);
      };
  };
  
  
• Os Catálogos:
• module CosPersistentState {
      interface CatalogBase {
          readonly attribute AccessMode access_mode; // read_only or not
  
          StorageHomeBase
            find_storage_home(in string storage_home_type_id)
              raises (NotFound);
  
          StorageObjectBase
            find_by_pid(in Pid the_pid) raises (NotFound);
  
          void flush(); // força a escrita persistente
          void refresh(); // refresca os objetos que estão no cache
          void free_all(); // libera a contagem de referências de todos objetos
          void close(); // termina a sessão e dá um flush
      };
      // ...
      local interface Session : CatalogBase {}
      interface TransactionalSession : Session {
      // ...
      };
  };
  
  
  
• Tipos de Sessão:
• básica (para acesso como em arquivos simples)
• transacional (para acesso como em BDs)
  
• Persistência Transparente
• Não há necessidade de definição separada de PSDL. 
• Nem todas implementações permitem.
  
• Em Java há 4 abordagens
1. pré-processador modifica o código
2. compilador especial de Java
3. pós-processador de bytecode
4. JVM especial
• Em Java, storage homes tem que implementar a seguinte interface:
• package CosPersistentState;
  public interface JStorageHome extends StorageHomeBase {
     public void persist(Object obj);
  }
  
• Em C++
• objetos herdam de CosPersistentState:StorageObjectBase
• tem que implementar o ODMG
  
• ponteiros tem que ser os smart pointersd_ref
• a operação mark_modified() tem que ser chamada explicitamente toda vez que algum objeto é modificado
  

Referências:

• Brose, Vogel e Duddy capítulo 13.
• O documento Persistent State Service 2.0 do OMG