Transparent Dynamic Reconfiguration
for CORBA
João Paulo A. Almeida(+), Maarten Wegdam(+)(++),
Marten van Sinderen(+), Lambert Nieuwenhuis(+)
[email protected] , [email protected],
[email protected], [email protected]
(+) University of Twente, Twente, The Netherlands
(++) Lucent Technologies, Twente, The Netherlands
Ricardo Koji Ushizaki
[email protected]
1
Introdução
Artigo apresentado no DOA’2001 –
http://www.cs.rmit.edu.au/conf/doa/2001/program.html
Propõe a criação de um Serviço de Reconfiguração
Dinâmica para CORBA
Nível do middleware de sistemas distribuídos –
transparente aos desenvolvedores
Ricardo Koji Ushizaki
[email protected]
2
Motivação
Reconfiguração Dinâmica:
 Definição
 Importância
 Reconfiguração planejada e evolucionária
Novas gerações de sistemas distribuídos consistem de
objetos utilizando algum middleware: CORBA, Java RMI
e DCOM.
Middleware facilita a criação de aplicações distribuídas.
Ricardo Koji Ushizaki
[email protected]
3
Processo De Reconfiguração Dinâmica
Entidades do sistema: Objetos, Componentes, SubSistemas.
Entidades são afetadas após reconfiguração do sistema:




Substituição
Migração
Adição
Remoção
Preservação de consistência – “correct state”:



Satisfazer integridade estutural
Entidades em um estado consistente (mutually consistent state)
Manter as invariantes da aplicação
Ricardo Koji Ushizaki
[email protected]
4
Serviço de Reconfiguração Dinâmica
Requisitos:
Corretude
 Aplicação geral
 Mínimo impacto na execução
 Transparência máxima
 Mínimo impacto no CORBA

Ricardo Koji Ushizaki
[email protected]
5
Proposta
Integridade estutural:


Manter as referências para objetos
Manter compatibilidade com antiga interface
Consistência




Safe State
Deter interações que impeça sistema de chegar ao safe
state
Detectar safe state alcançado
Aplicar reconfiguração
Ricardo Koji Ushizaki
[email protected]
6
Safe State
Como chegar ao safe state?

Interferir com atividades do sistema (requests)
3 tipos de requisições:



Blocking set
Necessárias para o sistema chegar ao safe state
Não envolvem objetos afetados
Finalmente, manter o estado da entidade e aplicar
reconfiguração
Ricardo Koji Ushizaki
[email protected]
7
Arquitetura do Serviço
LocationAgent
GenericFactory
Reconfiguration
Manager
Location
Agent
ReconfigurationManager
ReconfigurableObject
ReconfigurableObjectFactory
Capsule
Capsule A
Capsule A
Object
Object
Object
Factory
Application Objects
Dynamic Reconfiguration
Service
ReconfigurationAgent
Reconfiguration
Agent
Reconfiguration Manager – componente central
Location Agent – registro de Reconfigurable Agents
Reconfiguration Agents – filtra as requisições (requests)
Ricardo Koji Ushizaki
[email protected]
8
Criação de um Reconfigurable Object
1. create_object()
5. register_object()
Reconfiguration
Manager
6. returns reference
to reconfigurable
object
Location
Agent
2. create_object()
Capsule A
Reconfigurable
Object
Factory
3. creates the
object
4. register_object()
Ricardo Koji Ushizaki
[email protected]
Reconfigurable
Object
Reconfiguration
Agent
9
Substituição de um Reconfigurable Object
1. replace_object()
12. done
10. register_object()
Reconfiguration
Manager
11. remove_obj()
Location
Agent
5. notify_
reconfig()
9. set_state()
8. get_state()
2. create_object()
Capsule A
Reconfigurable
Object
Factory
Reconfigurable
Object
Capsule B
Reconfigurable
Object
Factory
7. no_reqs_pending()
6. start_freezing()
Reconfiguration
Agent
Ricardo Koji Ushizaki
[email protected]
3. creates
the object
Reconfigurable
Object
4. register_object()
Reconfiguration
Agent
10
Implementação
Ricardo Koji Ushizaki
[email protected]
11
Testes
Foi criado um protótipo do Serviço em Java, utilizando o
ORBacus 4.0.4.
Delay introduced by the middleware platform in
ORB-mediated invocations
Average delay (m s)
1,8
1,6
1,4
1,2
plain implementation
1
0,8
minimal interceptors
DRS interceptors
0,6
0,4
0,2
0
0 byte
128 bytes
2048 bytes
Size of results + argum ents
Ricardo Koji Ushizaki
[email protected]
12
Conclusão
Resultados dos testes indicam mínimo overhead
introduzido pelo uso do Serviço.
Solução isola objetos afetados, permitindo ao resto do
sistema de continuar executando.
Uso de portable interceptors instrui o middleware em obter
informações em tempo de execução.
Ricardo Koji Ushizaki
[email protected]
13