sistemas distribuídos - comunicação distribuída – corba

Comunicação Distribuída – CORBA

Prof. Adriano Teixeira de Souza

Estratégias diferentes que permitem a comunicação entre aplicações distribuídas.

Tipos distintos de comunicação em um sistema distribuído:

◦ Sockets

◦ RPC – Remote Procedure Call

◦ RMI - Remote Method Invocation

◦ CORBA – Commom Object Request Broker Architecture ◦ EJB – Enterprise Java Bean

◦ Web Services


Motivação: ◦ Socket

Desenvolvimento lento

◦ RPC Procedural

Dependente de linguagem

◦ RMI O.O

Dependente de Linguagem

◦ Suporte a diversas linguagens, possibilitando a

comunicação entre módulos escritos em linguagens distintas


Objetivo ◦ Tornar fácil a implementação de aplicações distribuídas

◦ Para sistemas Orientado a Objetos e procedurais

◦ Independentes de:

plataforma

sistema operacional

linguagem de programação

protocolo de comunicação

◦ Permitindo chamadas de procedimento remoto como se fossem locais


História ◦ OMG

A arquitetura CORBA é desenvolvida pela OMG (Object Management Group). www.omg.org

A OMG foi fundada em 1989 por oito membros fundadores (3Com, American Airlines, Canon, Data General, HP, Philips, Sun e Unisys).

No ano 2000 tinha mais de 800 membros, incluindo IBM e Microsoft (apenas como observadora).


CORBA - Common Object Request Broker Architecture,

Especificação que permite aos objetos de sistemas distribuídos comunicarem-se entre si de forma transparente

Componentes principais da OMA - Object Management Architecture ◦ Objetos da aplicação ◦ Facilidades CORBA ◦ Serviços de Objeto ◦ ORB


Conceito de ORB (Object Request Broker) ◦ componente que auxilia o cliente a invocar um

método em um objeto de forma transparente

(transparência de acesso)

localização do objeto

ativação do objeto se necessário

comunicar ao objeto sobre a requisição do cliente


Chamada através de um ORB


Objetivo: possibilitar que clientes invoquem métodos a

objetos remotos (objetos CORBA), e que ambos possam

ser implementados em linguagens distintas

A linguagem de implementação do cliente não precisa ser

necessariamente orientada a objetos

Funcionalidades

◦ invocações estáticas

interface remota do objeto CORBA é conhecida em tempo de

compilação (utilização dos stubs e skeletons)

◦ invocações dinâmicas

interface remota do objeto CORBA não é conhecida em

tempo de compilação


Estrutura de um ORB


Semântica de invocação ◦ semântica at-most-once (default)

◦ semântica OneWay

métodos sem resultados ou callbacks, o cliente não bloqueia na espera de uma resposta

◦ Semântica at-most-once

O cliente continua imediatamente e pode mais tarde bloquear-se à espera da resposta

Objeto CORBA: objeto remoto ◦ implementa uma interface IDL

◦ possui uma referência de objeto remoto

◦ capaz de responder a invocações aos métodos de sua interface


client server

proxy

or dynamic invocation

implementation

repository object adapter

ORB ORB

skeleton

or dynamic skeleton

client program

interface

repository

Request

Reply core core for A

Servant

A


Adaptador de objeto (Object Adapter) ◦ interliga os objetos CORBA e as classes do

servidor

◦ cria as referências a objetos remotos para os

objetos CORBA

◦ despacha cada RMI através de um skeleton

para o servidor apropriado

◦ ativa objetos (se necessário)

◦ CORBA 2.2: POA (Portable Object Adapter)

permite que aplicações e servidores sejam executados

em ORBs produzidos por desenvolvedores diferentes


Skeleton (servidor) ◦ geradas na linguagem do servidor por um compilador

IDL

◦ RMIs são despachadas através do skeleton apropriado a

um servidor

◦ marshaling e unmarshaling

Stubs/proxies (cliente)

◦ geradas na linguagem do cliente por um compilador IDL

◦ proxy (linguagens orientadas a objeto)

◦ stub (linguagens procedurais)

◦ marshaling e unmarshaling


Repositório de implementação

◦ ativa por demanda os servidores registrados, e localiza

os servidores em execução

◦ armazena tabela com o mapeamento dos nomes dos

adaptadores de objetos para suas implementações

◦ na ativação de objeto remoto, o hostname e o número

da porta no servidor são adicionados na tabela

◦ possibilita armazenar outras informações sobre os

servidores (e.g. controle de acesso)

◦ permite replicação

aumento de disponibilidade e tolerância a falhas


Repositório de interface

◦ provê informações sobre interfaces IDL registradas (e.g. métodos, argumentos, exceções)

◦ cliente sem proxy de objeto pode obter informações necessárias (métodos e argumentos)

◦ necessário para invocações dinâmicas

◦ nem todos os ORBs provêm um repositório de interfaces


Interface de invocação dinâmica

◦ permite que clientes façam invocações dinâmicas a objetos CORBA desconhecidos

◦ cliente obtém informações necessárias sobre um objeto CORBA a partir do repositório de interfaces, e utiliza esta informação para construir uma invocação e enviá-la ao servidor


Passo para uma Inovação Dinâmica 1. Identificar o objeto que queremos invocar

(provavelmente através do Trader Service do CORBAservices);

2. Recuperar sua interface (buscá-la no Repositório de Interfaces);

3. Construir a invocação;

4. Invocar a requisição, e receber os resultados.


Interface skeleton dinâmica

◦ permite um objeto CORBA aceitar invocações em uma interface sem skeleton

interface não era conhecida em tempo de compilação

◦ skeleton dinâmico

recebe a invocação

inspeciona o conteúdo da requisição para descobrir o objeto destino, o método para ser invocado e os argumentos

invoca o destino


Facilidades para definir módulos, interfaces, tipos, atributos e métodos

sintaxe similar a C++ incluindo mais algumas palavras-chaves

Módulos IDL

◦ permite agrupar interfaces e outros tipos IDL em unidades lógicas

◦ módulo define um nome de escopo (evita conflito entre nomes)

Interfaces IDL

◦ descrevem os métodos e atributos que são disponíveis por objetos CORBA que implementam a interface


Transparência de localização ◦ Tratamento igual para Função local

Deficiências de projeto e processo

Problemas com implementações

Firewalls


sistemas distribuídos - comunicação distribuída – corba

Technology