A Arquitetura CORBA

1
A Arquitetura CORBA

• Luciano Barbosa
• Rodrigo Caldas
• Wellington Ramos

Sistemas Distribuídos Novembro de 2003
2
Introdução

• CORBA (Common Object Request Broker Architecture)
• Solução aberta para o desenvolvimento de
  aplicações distribuídas orientadas a objeto em
  ambientes heterogêneos inicialmente especificada
  pela OMG.
• OMG Object Management Group
• Organização sem fins lucrativos composta de 800
  membros atualmente (desde 1989).
• Tem o objetivo de desenvolver, adotar e promover
  padrões para o desenvolvimento de aplicações em
  ambientes heterogêneos distribuídos.
• A organização prima pela interoperabilidade entre
  as diversas implementações de produtos CORBA.

3
CORBA

• É solução para interoperabilidade entre
  sistemas, comunicação entre objetos, aplicações 
  distribuidas, integração de sistemas legado,
  comunicação de aplicações na Internet e outros.
• A arquitetura deste padrão prevê mecanismos por
  onde um objeto pode enviar requisições ou receber
  respostas, para outros objetos em sistemas
  distribuídos de forma transparente.
• Oferece um mecanismo padrão para a definição de
  interfaces entre componentes e ferramentas para
  facilitar a implementação destas interfaces nas
  linguagens escolhidas pelos desenvolvedores.
• Proporciona escalabilidade e uma abordagem
  baseada em padrões.

4
Desenvolvimento CORBA

• É a forma como os objetos vão interagir entre
  si e que serviços (métodos) estarão disponíveis,
  isto também é conhecido como definição de
  interfaces, disponibilizadas em IDL, que é a
  ferramenta necessária para gerar o código que
  proverá a comunicação entre o cliente e o
  servidor ORB.
• Outro ponto importante é que as aplicações
  desenvolvidas para CORBA trabalham independente
  de sua localização da rede.

5
ORBObject Request Broker

• São elementos-chave na utilização da tecnologia
  CORBA.
• São encarregados por encaminhar rotinas que serão
  executadas remotamente, gerenciar o
  armazenamento, a interação e as comunicações das
  aplicações.
• É o middleware que estabelece os relacionamentos
  cliente-servidor entre os objetos.
• ORBs diferentes podem ter implementações
  diferentes e existem varias implementações ORBs
  que possuem rotinas diferentes para referenciar
  objetos.

6
ORBObject Request Broker

• Permite que um objeto faça uma solicitação a
  outro de forma transparente, local ou
  remotamente.
• O ORB esconde os seguintes detalhes
• o mecanismo de comunicação utilizado
• a localização do objeto servidor
• a forma de implementação do objeto
• seu estado de execução
• a plataforma de HW/SW em que está executando etc.

7
ORB
8
ORB vs. Outras soluções para comunicação

• O ORB apresenta várias vantagens em relação a
  outros tipos de middleware
• Inúmeros serviços agregados
• Invocações estáticas e dinâmicas
• Bindings com a maioria das linguagens (C, C,
  COBOL, Java, Smalltalk, Ada...)
• Sistema auto-descritivo (metadados)
• Transparência em vários níveis
• Serviços de segurança e transações
• Mensagens polimórficas

9
Interoperabilidade

• As versões anteriores da especificação CORBA não
  previam operação entre plataformas diferentes.
• Criação de um protocolo único de comunicação
• O GIOP.

10
Protocolos GIOP e IIOP

• General Inter-ORB Protocol GIOP
• Sintaxe construída para interações entre ORBs,
  definem um padrão de baixo nível para
  representações de dados.
• Idealizado para trabalhar com qualquer protocolo
  orientado à conexão.
• Internet Inter-ORB Protocol IIOP
• Projetado para permitir que ORBs interajam via
  Internet
• IIOP é GIOP implementado em TCP/IP, assim oferece
  mais confiabilidade no serviço.

11
Componentes de um ORB

• Um ORB é formado pelos seguintes componentes
• Stubs clientes
• Skeletons
• Repositório de Objetos
• Repositório de Interfaces
• Interface de Invocação Dinâmica (DII)
• Interface de Skeleton Dinâmica (DSI)
• Repositório de Implementação
• Adaptador de Objetos (OA)
• Interface do ORB

12
Componentes de um ORB
13
Stubs Clientes(Stubs)

• Os stubs clientes são as interfaces estáticas
  para os serviços (objetos).
• São responsáveis por tratar dos detalhes da
  comunicação entre clientes e servidores.
• Para o cliente, o stub é como um proxy local para
  um objeto servidor remoto.
• O stub cliente compõe uma mensagem com a
  identificação do método invocado e seus
  parâmetros e a envia ao servidor.
• Em seguida, bloqueia-se para aguardar a resposta
  à solicitação feita.

14
Stubs Servidores(Skeletons)

• São a parte correspondente aos stubs clientes, no
  ambiente servidor.
• Fornecem uma interface estática para cada serviço
  exportado pelo servidor.
• O skeleton obtém a identificação do método e os
  seus parâmetros da mensagem recebida e faz uma
  chamada local ao servidor.
• Ao ser completada a solicitação, envia uma
  mensagem com os resultados ao cliente.

15
Linguagem de Definição de Interface(IDL)

• A Interface Definition Language é usada para
  especificar a interface dos objetos servidores
  (dos serviços).
• A IDL é puramente declarativa, ou seja, não
  especifica nenhum detalhe de implementação.
• Através da IDL, definem-se quais os métodos
  disponíveis no servidor, seus parâmetros e tipos,
  valores de retorno, exceções, herança, eventos
  etc.
• A IDL estabelece uma espécie de contrato entre
  o servidor e seus clientes em potencial.

16
Invocação Estática

• É a forma mais usual de chamada de métodos em
  CORBA.
• A interface estática é gerada a partir da
  descrição do serviço (feita em IDL) e inserida
  diretamente no código dos stubs/skeletons.
• É útil quando se conhece, em tempo de compilação,
  as particularidades das operações que serão
  chamadas.
• Permite realizar interações síncronas e
  assíncronas (oneway).

17
Invocação Estática

• Vantagens
• Mais fácil de programar (similar a uma RPC)
• Verificação de tipos mais robusta (em tempo de
  compilação)
• Auto-documentação
• Melhor desempenho que as outras formas de
  interação
• Desvantagem
• É menos flexível

18
Invocação Dinâmica

• Permite que o cliente especifique, em tempo de
  execução, o objeto e o método que deseja invocar.
• O cliente, então, constrói a sua chamada
  através de uma seqüência de troca de mensagens
  com o Repositório de Interfaces.
• É mais flexível que o método estático, porém é
  mais difícil de programar e apresenta desempenho
  inferior.
• Também permite fazer chamadas síncronas adiadas
  (deferred synchronous) e callbacks.

19
Repositório de Objetos

• Contém informações necessárias para que o ORB
  localize e ative implementações de objetos
• Sempre que a implementação de um objeto é ativada
  no servidor, o hostname e o número da porta do
  servidor são adicionados ao mapeamento.
• É um repositório de metadados dinâmico para o ORB.

20
Repositório de Interfaces

• O Interface Repository contém uma base de dados
  com a definição das interfaces de todos os
  serviços conhecidos pelo ORB.
• É um repositório de metadados dinâmico para o ORB.

21
Interface de Invocação Dinâmica(DII)

• Permite que o cliente invoque um método no
  servidor sem que se tenha conhecimento, em tempo
  de compilação, de sua interface.
• Neste tipo de interação, portanto, não se usam
  stubs IDL.
• Os dados sobre o objeto remoto são obtidos a
  partir da base de dados do Repositório de
  Interfaces.

22
Interface de Skeleton Dinâmica(DSI)

• É o correspondente à DII, no lado servidor.
• Permite que os servidores sejam escritos sem que
  se tenha skeletons IDL previamente compilados no
  código do programa.
• É útil na implementação de pontes entre ORBs e
  também para fazer a comunicação entre o CORBA e
  outras plataformas de computação distribuída.

23
Repositório de Implementação

• O Implementation Repository é um repositório,
  em tempo de execução, para as classes que um
  servidor suporta, os objetos instanciados e suas
  identificações.

24
Adaptador de Objetos

• O Object Adapter é a cola entre o ORB e as
  implementações dos objetos no lado servidor.
• É responsável por
• Registrar as classes servidoras no Repositório de
  Implementação
• Ativar (instanciar) os objetos chamados, em tempo
  de execução, segundo a demanda dos clientes
• Receber as chamadas para os objetos e repassá-las
  aos mesmos (invocação de métodos)
• Gerar e gerenciar as referências de objetos (ORs).

25
Adaptador de Objetos

• Em resumo, um Adaptador de Objetos define como um
  objeto é ativado.
• O CORBA determina que todo ORB deve possuir um
  BOA (Basic Object Adapter), para garantir a
  portabilidade das aplicações.
• Normalmente, existe um adaptador de objetos
  diferente para cada linguagem suportada pelo ORB.
• Podem-se criar adaptadores para fins específicos.

26
Adaptador de Objetos
27
O Basic Object Adapter (BOA)

• Interface com a função de instanciar e dar
  suporte a uma ampla variedades de objetos.
• Características
• Presente na especificação CORBA até a revisão 2.1
• Problemas na especificação do BOA
• Aspectos importantes ficaram indefinidos
• Muita ambiguidade
• CORBA 2.2 substituiu o BOA pelo POA
• por algum tempo o BOA continuou sendo o adaptador
  oferecido pela maioria dos ORBs.
• Não possui portabilidade entre diversos ORBs.

28
O Portable Object Adapter (POA)

• É uma extensão do BOA.
• Características
• Especificação aprovada em março de 1997
• Substitui o BOA
• Permite que servidores CORBA sejam escritos de
  modo portável
• O código do lado do cliente pode ser escrito
  independente do ORB utilizado
• Pode ser ativado explicitamente ou por demanda
• Permite a criação de objetos persistentes

29
Referências de Objetos (ORs)

• As Object References identificam, de forma única,
  um objeto dentro de um dado sistema CORBA.
• Uma OR pode ser um nome ou identificador, a sua
  representação interna fica a cargo de cada ORB.
• Os clientes obtêm ORs a partir de arquivos,
  serviços de diretórios, do Repositório de
  Interfaces ou como resultado de invocação de
  métodos.

30
Serviços CORBA

• Nomes
• Permite que os componentes localizem-se pelo
  nome.
• Os objetos podem ser acoplados a serviços como
  X.500, OSF DCE e NIS.
• Eventos
• Permite que os objetos registrem seu interesse em
  eventos específicos.
• Viabiliza uma maneira alternativa de comunicação
  entre os objetos (acoplamento fraco).

31
Serviços CORBA

• Ciclo de Vida
• Define operações para a criação, destruição,
  cópia, e movimentação de objetos no barramento.
• Trader
• Permite que um objeto descubra outro baseado em
  suas características, assim como um objeto também
  pode anunciar suas funcionalidades e cobrar pelo
  seu uso.
• Persistência
• Fornece uma interface única para o armazenamento
  de objetos em arquivos comuns, BDRs ou BDOOs.

32
Serviços CORBA

• Query
• Permite realizar consultas a objetos.
• Usa um superconjunto da SQL a OQL, do ODMG.
• Transações
• Fornece facilidades de commit de duas fases, com
  transações simples ou aninhadas.
• Concorrência
• Viabiliza a existência de um Lock Manager para o
  sistema.

33
Serviços CORBA

• Relacionamento
• Cria relacionamentos entre componentes quaisquer.
• Permite implementar integridade referencial,
  containment relationships e outras formas.
• Externalização
• Permite converter dados de/para um objeto em uma
  forma linear (stream).
• Licensing
• Faz a contabilização de uso de um componente, em
  vários níveis.

34
Serviços CORBA

• Propriedades
• Pode-se associar propriedades (valores nomeados)
  a um componente.
• Por exemplo um label, uma data, ...
• Tempo
• Permite a sincronização do tempo em um ambiente
  distribuído, além da definição de eventos
  dependentes de tempo.

35
Serviços CORBA

• Segurança
• Define um modelo de segurança completo para
  objetos distribuídos.
• Dá suporte à autenticação, controle de acesso,
  confidencialidade e não-repúdio.
• Coleções
• Fornece interfaces CORBA para a criação e
  manipulação dos tipos mais comuns de coleções.

36
Mais informações...

• Object Management Group
• http//www.omg.org
• Semana de Computação do ICMC (Out/2001)
• http//lasdpc.icmc.usp.br/palestras/arquivos/mini
  curso_corba.zip
• Notas Didáticas (Nov/2002)
• Desenvolvimento de Aplicações Distribuídas usando
  a Arquitetura CORBA
• Ricardo R. Santos, Mário M. Teixeira, Marcos
  Santana, Regina Santana
• http//lasdpc.icmc.usp.br/producao/files/nd_corba_
  ps.zip