Sistemas Distribuídos
Controle do Ciclo de Vida de
Objetos
Especialização em Redes de
Computadores
Prof. Fábio M. Costa
Instituto de Informática - UFG
Visão Geral
• Ciclo de vida de objetos simples
– Criação de objetos distribuídos
– Migração de objetos distribuídos
– “Deleção” de objetos distribuídos
• Aspectos avançados:
– Objetos compostos
– Ciclo de vida de objetos compostos
• Visão do projetista do cliente
• Visão do projetista do servidor
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
2
Ciclo de Vida de Objetos Simples
Motivação
• Ciclo de vida de objetos distribuídos é diferente do
ciclo de vida de objetos locais
• Criação
– Onde criar o objeto?
• Migração
– Para onde copiar/mover um objeto?
– Como resolver a heterogeneidade na representação dos
dados e código do objeto?
• Deleção:
– Coleta de lixo não funciona
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
4
O Ciclo de Vida
copy
move
available
create
Original: Wolfgang Emmerich, 2000
delete
unavailable
Prof. Fábio M. Costa - Instituto de Informática / UFG
5
Criação: Visão do Programador
do Cliente
• Clientes podem desejar criar objetos em máquinas
remotas
• Isto pode ser feito através de fábricas
• Fábrica: um objeto que cria outros objetos
• Fábrica abstrata: oculta detalhes de criação
• Máquinas remotas (e suas respectivas fábricas)
devem ser identificadas de maneira transparente
de localização
• Isto é feito através de “buscadores de fábricas”
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
6
Fábricas
LeagueMgmnt
AbstractFactory
CreateTeam()
CreatePlayer()
CricketFactory
CreateTeam()
CreatePlayer()
Team
SoccerFactory
CreateTeam()
CreatePlayer()
SoccerTeam
Player
SoccerPlayer
Original: Wolfgang Emmerich, 2000
CricketTeam
CricketPlayer
Prof. Fábio M. Costa - Instituto de Informática / UFG
7
Fábricas para Objetos
Distribuídos
• Exemplo: Administração de Futebol
– Times e Jogadores podem precisar ser criados
em máquinas diferentes
– Deve-se instalar uma Fábrica em cada máquina
– Requisitar a criação de objetos na forma de uma
requisição de objetos normal (à Fábrica)
– Objetos são criados de maneira transparente de
localização
• Problema: Como encontrar fábricas?
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
8
Buscadores de Fábricas
• Localização não deve ser transparente para
todos!
• Administradores devem ser capazes de
decidir onde criar novos objetos
• Políticas são implementadas usando objetos
do tipo FactoryFinder (buscador)
• Um FactoryFinder exporta uma operação
find_factories que retorna uma fábrica
apropriada
– portanto implementando a política de localização
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
9
Criando Objetos Distribuídos
:Client
:Factory
Finder
f:Team
Factory
f=find_factories(“Team”)
newteam=create_team()
newteam:
Team
• O novo objeto time será criado na máquina que
hospeda a fábrica TeamFactory f
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
10
Criação: Visão do Programador
do Servidor
• O programador do servidor deve implementar as
fábricas
• Fábricas precisam registrar os objetos criados
através da interface do middleware
– CORBA ORB Interface
– Java RMI/Registry
• Fábricas genéricas: para qualquer tipo de objeto
• Fábricas específicas para cada tipo de objeto:
– Determinam a política de ativação de objetos
– Pode englobar uma fábrica genérica
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
11
Uso de Fábricas Genéricas
:Client
f:Team
Factory
:Generic
Factory
create_team(“BvB”)
t=create_object(“Team”)
t:Team
set_name(“BvB”)
• Uma fábrica genérica cria objetos “brutos” e então
uma fábrica específica realiza as inicializações
necessárias
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
12
Criação: Visão do Administrador
• Administradores precisam prover buscadores de
fábricas que implementam as políticas de criação
definidas
• Buscadores de fábricas precisam ser localizáveis
através de
– Serviço de nomes
– Trading
• As implementações de fábricas e buscadores de
fábricas precisam ser registradas no middleware
– Repositório de implementações de CORBA
– Java/RMI Registry
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
13
Migração
• Objetos podem ter que ser movidos ou
copiados para outras máquinas devido a
– Descontinuação de máquinas
– Balanceamento de carga
• Operações de cópia e movimentação de
objetos fazem parte do serviço de migração
• Diferentes perspectivas:
– Programador do cliente, do servidor e
administrador
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
14
Migração: Visão do Programador
do Cliente
:Client
:Naming
Context
ff:Factory
Finder
:Player
ff=resolve(“Hosts”,”BvB”)
move(ff)
• Move objeto jogador (player) para a nova
localização, a ser decidida pelo objeto
FactoryFinder ff
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
15
Exemplo: Interface de Migração
de CORBA
module CosLifeCycle{
interface LifeCycleObject {
LifeCycleObject copy(in FactoryFinder there,
in Criteria the_criteria)
raises(...);
void move(in FactoryFinder there,
in Criteria the_criteria)
raises(...);
...
};
• Objetos migráveis precisam ser sub-tipos da
interface LifeCycleObject
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
16
Movendo Objetos: Visão do
Programador de Servidor
p:Player
move(ff)
ff:Factory
Finder
f:Player
Factory
np:
:Object
Player Adapter
f=find_factories(crit)
np=create_player()
transfer_values(...)
transfer_obj_ref(p)
• Heterogeneidade de dados é resolvida durante a
transferência de valores dos atributos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
17
Cópia: Visão do Programador de
Servidor
p:Player
copy(ff)
:ff:Factory
Finder
f:Player
Factory
np:
Player
f=find_factories(crit)
np=create_player()
transfer_values(...)
• Em essência, uma operação de movimentação
simplificada
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
18
Migração: Visão do
Administrador
• Operações de migração são freqüentemente
iniciadas por administradores
• Requisição de operações de cópia / movimentação
feita através de alguma ferramenta de
administração do sistema
• O administrador deve assumir as mesmas
responsabilidades da criação de objetos:
– Prover um buscador de fábrica
– Tornar o buscador localizável
– Registrar as fábricas e buscadores junto ao middleware
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
19
Migração: Uma Avaliação da
Transparência
• Criação de objetos transparente de localização:
através dos buscadores de fábricas
• Migração transparente para o programador do
cliente
• Migração não transparente para o programador do
servidor, dada a necessidade de:
– Herdar da interface LifeCycleObject
– Implementar as operações copy / move
• Transparência de replicação não é contemplada
pelos serviços de controle de ciclo de vida
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
20
Deleção de Objetos:
Integridade Referencial
• Integridade referencial: garantia de que
referências de objetos permanecem válidas
• Em particular, objetos servidores não serão
deletados enquanto algum cliente possuir
referências para os mesmos
• Quase impossível garantir completa
integridade referencial para objetos
distribuídos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
21
Deleção: Visão do Programador
do Cliente
• Deleção implícita
• Deleção explícita
– Realizada através de
coleta de lixo quando o
objeto não é mais
referenciado
– Mais cara devido à
contagem de refs.
– Não pode ser usada se
contagem de refs. for
impossível
– Garante integridade
referencial até certo ponto
Original: Wolfgang Emmerich, 2000
– Deleção é requisitada
por algum cliente ao
assumir que o objeto
ficou obsoleto
– Sem o overhead de
contagem de refs.
– Pode ser usado quando
contagem de refs. não
puder ser realizada
– Sem garantias de
integridade referencial
Prof. Fábio M. Costa - Instituto de Informática / UFG
22
Deleção: Interfaces CORBA
module CosLifeCycle{
exception NotRemovable { string reason; };
interface LifeCycleObject {
...
void remove() raises {NotRemovable};
}
...
};
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
23
Deleção: Visão do Programador
do Cliente
• Deleção Explícita
:Client
t:
Team
remove()
• Deleção Implícita
:Garbage
Collector
t:
Team
remove()
• Deleção explícita não é transparente para o
programador do cliente!
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
24
Deleção: Visão do Programador
do Servidor
• O programador do servidor precisa
determinar como deletar um objeto
– Liberar os recursos usados pelo objeto
– Manter a integridade de objetos relacionados
• Implementar um destrutor
• Em CORBA: implementar a operação
remove( ) da interface LifeCycleObject
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
25
Deleção: Visão do Programador
do Servidor
t:Team
remove()
:Player
:Player
:Player
release()
release()
release()
...
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
26
Deleção: Visão do Administrador
• Deleção de instâncias versus deleção de tipos
• Instâncias:
– Remover, do serviço de nomes, a referência ao objeto
deletado
– Pode causar a coleta de lixo se esta for a última referência
ao objeto no serviço de nomes
• Tipos: Remover:
– Do serviço de nomes: buscador de fábrica
– Do repositório de implementações: objetos, fábricas e
buscador de fábrica
– Do repositório de interfaces: definições de tipos do objeto
e da fábrica
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
27
O Que Está Faltando: Replicação
• Cópias feitas pelo serviço de ciclo de vida são
separadas e não evoluem juntos
• O serviço de ciclo de vida não pode ser usado para
replicação de objetos servidores “com estado”
(statefull)
• Objetos replicados refletem as mudanças de estado
uns dos outros e, portanto, evoluem juntos
• Replicação é tipicamente usada para
– Balanceamento de carga
– Tolerância a falhas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
28
Objetos Compostos
Objetos Compostos: Projeto
• Consiste de objetos atômicos
• Controla o ciclo de vida dos objetos atômicos
• Uso de diagramas de classe UML para modelar os
objetos compostos:
Club
1
1
*
*
Team
Player
1 consists of >
has > 1
Game
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
30
Validação de um Modelo de
Composição
• As seguintes perguntas podem ser usadas para
validar um modelo de composição de objetos:
– Se um objeto composto migra, podem todos os seus
componentes migrarem também?
– Se um objeto composto é deletado, está ok remover
todos os seus componentes?
– Pode um objeto componente migrar sem deletar a
relação de composição?
• Se a resposta para alguma destas perguntas é
NÃO, então o modelo de composição é falho
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
31
Objetos Compostos:
Implementação
• A implementação de composição de objetos pode
ser delegada para um serviço de Relacionamentos
– Ex.: CORBA Relationship Service
• Relacionamentos devem ser implementados como
objetos
– Objetos não devem estar cientes de que estão
relacionados
– Relacionamentos devem ser navegáveis em ambas as
direções
– Pode-se associar comportamento aos relacionamentos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
32
CORBA Relationship Service
• Relacionamentos em CORBA são providos por
meio de um serviço em camadas
Reference and Containment
Graphs of Related Objects
Base Relationships
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
33
Relacionamentos Base
• Definidos por um conjunto de papéis que dois ou
mais objetos desempenham (propriedade, “está
contido”, referenciação, etc.)
• Objetos podem desempenhar vários papéis
• A cardinalidade define o número máximo de
relacionamentos em que um papel pode estar
envolvido
• O grau define o número de papéis de um
relacionamento (ex.: binário, ternário)
• Relacionamentos podem ter atributos
• Objetos relacionados formam um grafo de nodos
(objetos) e arestas (relacionamentos)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
34
CORBA Relationship Service
RelationshipFactory
relationship_type
degree
named_role_types
RelationshipIterator
Relationship
creates
named_roles
destroy()
create()
iterates
next_one()
next_n()
destroy()
creates
Role
related_object
RoleFactory
role_type
max_cardinality
min_cardinality
related_object_types
create_role()
Original: Wolfgang Emmerich, 2000
creates
get_other_related_object()
get_other_role()
get_relationships()
destroy_relationships()
destroy()
check_minimum_cardinality()
link()
Prof. Fábio M. Costa - Instituto de Informática / UFG
unlink()
35
Exemplos de Relacionamentos e
Papéis
Relationship
Role
Contains
ContainedIn Home
Original: Wolfgang Emmerich, 2000
Away
Has
Game
Prof. Fábio M. Costa - Instituto de Informática / UFG
36
Uso do Serviço de
Relacionamento
• Relacionando objetos usando papéis e
relacionamentos
<<object>>
Spurs:Club
<<role>>
:Contains
<<object>>
klinsi:Player
<<rel>>
:Containment
Original: Wolfgang Emmerich, 2000
<<role>>
:ContainedIn
<<object>>
Spurs1:Team
<<role>>
:Contains
<<rel>>
:Containment
<<role>>
:ContainedIn
<<role>>
:Home
<<rel>>
:Reference
<<role>>
:Away
<<object>>
ManU1:Team
Prof. Fábio M. Costa - Instituto de Informática / UFG
37
Grafos de Objetos Relacionados
• A segunda camada implementa a travessia do
grafo de objetos relacionados, usando
– Busca em profundidade
– Busca em largura
– Melhor-primeiro
• Interface básica: Node
– Serve como um proxy para objetos relacionados
– Conhece os relacionamentos dos quais o objeto
participa
• Interface Traversal oferece suporte para visitar os
próximos n nodos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
38
Exemplo de Grafo de Objetos
Relacionados
<<object>>
Spurs:Club
<<node>>
:Node
<<object>>
Spurs1:Team
<<role>>
:Contains
<<rel>>
:Containment
Original: Wolfgang Emmerich, 2000
<<role>>
:ContainedIn
<<object>>
klinsi:Player
<<node>>
:Node
<<role>>
:Contains
<<role>>
:Home
<<rel>>
:Reference
<<rel>>
:Containment
<<role>>
:Away
<<role>>
:ContainedIn
<<node>>
:Node
Prof. Fábio M. Costa - Instituto de Informática / UFG
<<node>>
:Node
<<object>>
ManU1:Team
39
Relacionamentos de Referência
e de Conteúdo
• O Serviço de Relacionamento pode prover
uma implementação direta da semântica de
composição em UML
• Separação entre relacionamentos de
referência e de conteúdo
• Provisão destes dois relacionamentos como
subtipos de papéis e relacionamentos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
40
Referência e Conteúdo
CosRelationships
CosContainment
CosRelationships::Relationship CosRelationships::Role
Relationship
ContainsRole ContainedInRole
CosReference
CosRelationships::Relationship CosRelationships::Role
Relationship ReferencesRole ReferencedByRole
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
41
Ciclo de Vida de Objetos
Compostos
Ciclo de Vida de Objetos
Compostos
• Aplica-se as operações de ciclo de vida para os
objetos raiz
• Todos os nodos que estão no fecho transitivo do
relacionamento de conteúdo serão
copiados/movidos/deletados
• Todos os relacionamentos internos àquele fecho
serão copiados/movidos/deletados
• Todos os objetos que são conectados àqueles
nodos serão copiados/movidos/deletados
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
43
Exemplo: Cópia de um Objeto
Composto
:Client
copy
:Node
Spurs:Club
:Role
:Rel.
:Role
:Node
copy
copy
Original: Wolfgang Emmerich, 2000
copy
copy
copy
Prof. Fábio M. Costa - Instituto de Informática / UFG
44
Objeto Composto Copiado
<<object>>
Spurs:Club
<<node>>
:Node
<<object>>
Spurs1:Team
<<role>>
:Contains
<<rel>>
:Containment
<<role>>
:ContainedIn
<<object>>
klinsi:Player
<<node>>
:Node
<<role>>
:Contains
<<role>>
:Home
<<rel>>
:Reference
<<rel>>
:Containment
<<role>>
:Away
<<node>>
:Node
<<role>>
:Contains
<<rel>>
:Containment
<<object>>
Spurs:Club
Original: Wolfgang Emmerich, 2000
<<role>>
:ContainedIn
<<role>>
:Home
<<rel>>
:Reference
<<node>>
:Node
<<role>>
:Contains
<<rel>>
:Containment
<<role>>
:ContainedIn
<<node>>
:Node
<<role>>
:ContainedIn
<<object>>
Spurs1:Team
Prof. Fábio M. Costa - Instituto de Informática / UFG
<<node>>
:Node
<<object>>
ManU1:Team
<<node>>
:Node
<<object>>
klinsi:Player
45
Pontos-Chave
• O controle do ciclo de vida de objetos distribuídos
é mais complicado do que no caso de objetos
locais
• Criação de objetos em máquinas remotas é obtida
através de fábricas
• Transparência de localização é obtida através de
buscadores de fábricas, os quais são proxies paras
as máquinas remotas
• Deleção de objetos pode ser implícita ou explícita
• Integridade referencial não pode ser garantida em
geral
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
46
Pontos-Chave
• Freqüentemente, vários objetos distribuídos tem o
mesmo ciclo de vida
• Composição de objetos pode ser usada para
agrupar estes objetos através de relacionamentos
• A implementação de objetos compostos pode ser
suportada por um serviço de Relacionamento
• A integração dos serviços de Relacionamento e
Ciclo de Vida permite a implementação de
controle de ciclo de vida para objetos compostos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
47