ricardo koji ushizaki [email protected] transparent dynamic reconfiguration for corba joão paulo a....

Ricardo Koji Ushizaki [email protected]

1

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


2

Introdução

Artigo apresentado no DOA’2001 – http://www.cs.rmit.edu.au/conf/doa/2001/program.htmlPropõe a criação de um Serviço de Reconfiguração Dinâmica para CORBANível do middleware de sistemas distribuídos – transparente aos desenvolvedores

http://www.cs.rmit.edu.au/conf/doa/2001/program.html


3

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.


4

Processo De Reconfiguração Dinâmica

Entidades do sistema: Objetos, Componentes, Sub-Sistemas.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


5

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


6

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


7

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


8

Arquitetura do Serviço

Reconfiguration Manager – componente centralLocation Agent – registro de Reconfigurable AgentsReconfiguration Agents – filtra as requisições (requests)

Capsule ACapsule ACapsule

LocationAgent

Factory

ReconfigurationManager

ReconfigurationAgent


ReconfigurableObjectFactory

ReconfigurableObject


GenericFactory

LocationAgent

ObjectObjectObject

Application Objects

Dynamic ReconfigurationService


9

Criação de um Reconfigurable Object

LocationAgent





Capsule A

1. create_object()

3. creates theobject

2. create_object()

4. register_object()

6. returns referenceto reconfigurable

object



10

Substituição de um Reconfigurable Object




Capsule B

LocationAgent





Capsule A

1. replace_object()

2. create_object()


3. createsthe object

6. start_freezing()

7. no_reqs_pending() 4. register_object()

9. set_state()

12. done

11. remove_obj()

5. notify_reconfig()

8. get_state()


11

Implementação


Client

ClientRequest

Interceptor

ServerRequest

Interceptor

ClientRequest

Interceptor

Object Request Broker Core

send_request: - copy threadcontext intorequest servicecontext

receive_exception: - if exception causedbecause ofreconfiguration, waitnotification andreissue request (viaLocationForward)(distributed queue)

receive_request: - extract ‘invocation path’- during reconfigurationfilter requests (throwexception to queue)- append id of target objto invocation path andcopy into thread context- increment # incomingrequests for target obj

send_reply: send_other: send_exception: - decrement #incoming requestsfor target

Reconfig.Agent

receive_exception: - wait notification andreissue request (viaLocationForward)

Reconfig.Manager

LocationAgent

request flow (decomposedORB-mediated invocations)reply flow (decomposedORB-mediated invocations)

ORB-mediated invocations

intra-capsule interactions

Factory

application

infrastructure


12

Testes

Foi criado um protótipo do Serviço em Java, utilizando o ORBacus 4.0.4.

00,20,40,60,8

11,21,41,61,8

Ave

rage

del

ay (m

s)

0 byte 128 bytes 2048 bytes

Size of results + arguments

Delay introduced by the middleware platform inORB-mediated invocations

plain implementation

minimal interceptors

DRS interceptors


13

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] transparent dynamic reconfiguration for corba joão paulo a....

Documents