CORBA – Common Object Request Broker Architecture

Carolina de Oliveira Cunha

Lenita Martins Ambrosio

Victor da Fonseca Santos

Introdução

OMG (Object Management Group): uma organização formada por empresas de diferentes ramos da informática que trabalham sem fins lucrativos, para promover a criação e elaboração de modelos e padrões que proporcionem a interoperabilidade entre aplicações que usam tecnologia OO.

Criou a arquitetura CORBA

O que é CORBA?

CORBA (Common Object Request Arquitecture Broker)

Padrão proposto pela OMG

Estrutura comum para o desenvolvimento utilizando técnicas de OO em redes heterogêneas

Propõe a interoperabilidade local ou remota entre aplicações, independente das linguagens de programação em que foram desenvolvidas e sobre quais plataformas serão executadas

O que é CORBA?

Objetivo: promover a intercomunicação de objetos distribuídos em uma rede de computadores, a fim de executar alguma tarefa

Porém o CORBA é uma parte de uma outra tecnologia proposta pela OMG, chamado OMA (Object Management Architecture)

O que é CORBA?

Composto por 4 componentes principais:

ORB: define um barramento comum para troca de mensagens entre os objetos.

Objetos de serviço: ampliam a funcionalidade do ORB e gerenciam os objetos

Facilidades comuns: definem as interfaces no nível da aplicação.

Objetos da aplicação: objetos utilizados pela aplicação do usuário final.

Arquitetura do Modelo de Referência

Modelo de Objetos

Objetos distribuídos CORBA são pequenas partes de um sistema maior

Essas partes estão distribuídas na rede e podem ser acessados por métodos de invocação

Objetos clientes podem ser remotos ou não

Semântica dos Objetos

Principal característica: disponibilizar serviços a um determinado cliente, onde este é qualquer entidade capaz de requisitar tais serviços.

A seguir algumas semânticas que serão abordadas no corpo deste trabalho:

Semântica dos Objetos

Objetos: entidade de identidades encapsuladas, com a capacidade de prover serviços aos clientes.

Requisições: evento que pode ser utilizado por um cliente para solicitar um serviço de um determinado objeto. Nesta operação, deve conter informações do tipo da operação executada, o objeto alvo, zero ou mais parâmetros e alguns textos adicionais para a requisição.

Formulário de requisição: descrição ou padrão que podem ser avaliados ou executados em vários tempos para provocar uma emissão de pedido;

Valores: algo que pode ser legalmente utilizada como parâmetro em uma requisição;

Referência a objetos: determinado valor que se relaciona especificamente a um determinado objeto.

Semântica dos Objetos

Criação e destruição de objetos: objetos podem ser criados ou destruídos de acordo com as necessidades do pedido de um emissor.

Tipos: identificação de uma entidade que possui características associadas ao seu valor. Os "tipos" são usados para restringirem a possibilidade de determinados parâmetros ou caracteres sejam apresentados como resultados.

Tipos Básicos: 16 bits, 32 bits e 64 bits; precisão simples (32 bits), precisão dupla (64 bits); caracter; booleano; string; constantes.

Tipos de Construções Possíveis: Tipo seqüência; tipo matriz; tipo interface; tipo record.

Interfaces: um conjunto de operações que podem ser requeridas por um cliente satisfazendo suas necessidades.

Semântica dos Objetos

Operações Entidade identificadora que denota os serviços que podem

ser requeridos e identificados por um identificador de operações.

As informações necessárias para sua ativação (envio de parâmetros, retorno de resultados, tratamento de exceções, semântica e informação de contextos) são relacionadas em sua assinatura.

Na especificação CORBA, as "operações" são tratadas de forma genérica.Em outras palavras, a mesma operação para vários objetos de diferentes características. Isso é possível, pois há uma total desvinculação dos detalhes da implementação de uma interface e também porque há utilização de herança.

Parâmetros: valores necessários para a execução de uma determinada operação, dados no momento da requisição de um determinado serviço. Os parâmetros se caracterizam por:

Modo: sentido que flui a informação representada pelo parâmetro, referenciando-se sempre com o servidor, podendo ser in, out, in-out.

Tipo: está relacionado aos possíveis valores que podem ser transmitidos por meio desse parâmetro.

Valor de Retorno: parâmetro out especial que tem como finalidade simplesmente transmitir, quando necessário, o resultado de uma operação.

Exceções: indicam que uma requisição a uma operação não foi executada corretamente. Em outras palavras, ocorreu um erro durante a prestação de um determinado serviço. Os tipos de erros que podem ocorrer ou estão ligados ao sistema propriamente dito ou a própria implementação do objeto que provê tal serviço desejado.

Contextos: informações adicionais e especiais, diferenciando-se dos valores dos parâmetros tradicionais. Entretanto, apesar de serem valores especiais, estes podem afetar no resultado de uma operação.

Semântica dos Objetos

Semântica dos Objetos

Semânticas de execuções: existem duas formas de se executar uma operação:

No máximo uma: se uma determinada operação foi executada com sucesso, é por que a mesma fora executada uma única vez, com sucesso. Outra possibilidade: havendo a emissão de uma exceção, significa dizer que a operação fora executada apenas uma vez e fora possível, nesta única execução da operação, alcançar o resultado desejado.

Melhor Esforço: não é esperado, pelo cliente, nenhum tipo de resultado da operação, por isso o cliente não precisa ficar ocioso por uma resposta. Para que um cliente nunca fique esperando por um resultado de uma operação que nunca virá, as informações necessárias sobre a semântica da execução estão anexadas pela assinatura, garantindo assim que os clientes e servidores fiquem cientes da natureza da operação (no máximo uma – melhor esforço)

Semântica dos Objetos

Atributos: declarações feitas para permitir a manipulação de valores do objeto

servidor.

Um atributo equivale logicamente a declaração de funções de acesso (uma para receber o valor do atributo e outra para escolher o valor do atributo). Entretanto um atributo pode ser definido como só de leitura.

Herança: conceito herdado do Paradigma de Orientação a Objeto, adotado e

utilizado pela especificação CORBA.

O CORBA permite utilizar herança para criar tanto novas interfaces como novos objetos. Ele implementa múltipla herança, porém não é possível herdar de duas classes que tenham mesmo nome de operação ou de atributo.

Não é possível alterar os nomes das operações ou atributos herdados nas classes derivadas, podendo apenas serem redefinidos nomes de tipos, constantes ou exceções.

O CORBA ainda permite múltipla herança com metaclasses (metaclasse é uma classe de objetos criada em tempo de execução).

Arquitetura CORBA

Repositório de Interfaces

Componentes da Arquitetura CORBA

Clientes

Toda entidade responsável por invocar uma determinada operação sobre uma implementação de objeto.

Os detalhes utilizados para que seja feito esse acesso aos serviços de um determinado objeto é transparente e dispensável do conhecimento do cliente, precisando o mesmo apenas saber interagir com a interface do tal objeto.

Essa invocação feita pelo cliente poderá ser feita utilizando-se o stub ou utilizando-se um conjunto de rotinas de invocações feitas dinamicamente através da interface DII

Implementação de Objetos

Operações que podem ser implementadas em uma interface ORB IDL.

Tem informações de objetos, como dados internos, os códigos de seus métodos e seus respectivos procedimentos de ativação e desativação determinados na criação do objeto.

Componentes da Arquitetura CORBA

ORB

Interface ORB

Stub

Skeleton

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

Interface de Esqueleto Dinâmico (DSI)

Adaptador de Objeto

Componentes da Arquitetura CORBA

ORB - Object Request Broker

Middleware da especificação CORBA

Uma das partes mais importantes do CORBA

Componente que define o barramento comum, criado para facilitar a comunicação entre objetos

Permite que objetos façam, de forma transparente, requisições a objetos que podem estar localizados localmente ou remotamente

O usuário não precisa se preocupar onde tal objeto está localizado, em que sistema operacional ele roda ou qual programa foi usado para desenvolvê-lo.

ORB - Requisições

É um pedido feito pelo cliente ao ORB

Componentes de uma requisição:

Referência ao Objeto: identifica o objeto desejado

Operação: identifica qual a operação deve ser executada

Parâmetros: dados necessários para a execução da operação;

ORB - Requisições

Quando um cliente invoca uma operação, a ORB fica responsável por encontrar a implementação do objeto, sua ativação e se necessário, entregar a requisição ao objeto e retornar qualquer resposta a quem o invocou. O cliente faz uma requisição Com isso, invoca ou cria uma rotina do Stub. A

implementação do objeto não precisa saber o tipo de método de invocação foi utilizado

O pedido é repassado para o ORB que fica responsável em encontrar a implementação do objeto, para então transmitir os parâmetros e o controle para essa implementação, tudo isso utilizando um Skeleton IDL específico da interface e através do adaptador de objetos

Então, a implementação do objeto acessa o ORB através de um adaptador de objetos, retornando para o cliente o resultado da operação

ORB - Referência a objetos

Para um cliente realizar uma requisição a um objeto, precisa ter uma referência ao mesmo, é importante dizer que cada objeto possui uma identificação única.

Existem várias maneiras de se obter uma referência a objeto: Criação de Objetos: o CORBA cria objetos. Os objetos são

criados por meio de invocações sobre objetos-fabricas, localizados no servidor de objetos. Essa operação gera uma referência ao objeto criado.

Serviço de Diretório: é permitido ao cliente invocar um determinado tipo de serviço de procura, para que possa achar referências a objetos.

Conversão de Referência em String e Vice-Versa: permite a conversão de uma referência a objeto em uma string, podendo a mesma futuramente ser recuperada e ser transformada novamente em referência a objeto.

ORB

Os serviços restantes que fazem do ORB um middleware, estão relacionados aos serviços a nível de sistemas, que oferecem outros tipos de serviços como: segurança, persistência entre outros.

O ORB ainda apresenta algumas deficiências: falta de mecanismos de controle de concorrência, de

balanceamento de carga e de coleta de lixo Não se dispõe de servidores de tolerância a falhas, o

que é feito para uma maior confiabilidade é a replicação de objetos.

não trabalham com produtos "chaves" das empresas de hoje, que são justamente monitores de processamento de transações, sistemas de banco de dados orientados a objetos e nem relacionais, dificultando assim a integração do ORB ao ambiente cliente/servidor já existente nas empresas.

Invocações

Processo de se chamar um método para que seja feito um acesso a um serviço de um objeto

Três formas de invocações existentes no CORBA:

Invocação Síncrona: o cliente fica travado esperando o resultado

Invocação Síncrona Deferida: o cliente pode executar outras chamadas e posteriormente receber os seus resultados.

Invocação ONEWAY: é usada pelo cliente quando não necessita de resultado, ficando livre para continuar seu processamento.

Dois diferentes tipos de processos de invocações: Estática e Dinâmica

Invocação Estática

Gerada diretamente em um formulário do stub, e compilada pelo compilador IDL

O cliente está ciente de quais objetos e métodos estão disponíveis além de ter todas as interfaces do sistema já definidas.

É bom para programas que na hora de compilar a invocação, sabem quais as operações que vão precisar usar.

Stubs

Estão localizados no lado do cliente

Promovem interfaces estáticas para criar e enviar requisições aos serviços desejados

São gerados a partir da compilação da interface do cliente.

Quando um cliente deseja chamar um método de um objeto, basta apenas indicar qual o objeto que deseja

O stub que receber essa chamada, localiza o objeto desejado, transforma a chamada para que possa ser enviada pela rede e a transmite para o ORB

A comunicação entre o stub e o ORB se dá por meio de interfaces privadas.

Skeletons

Executam função similar ao Stub do cliente, no "lado" do servidor.

Tem como função encontrar os serviços que são solicitados pelo Stub.

O Skeleton receberá na sua criação o "pacote" do ORB, e irá descompactá-lo e envia-lo para a implementação do objeto

A requisição será recebida pelo objeto que irá executá-la, havendo alguma resposta, esta será enviada de volta ao cliente

O fato de existir um Skeleton, não implica em dizer que existe um Stub do outro lado, pois a invocação a ele pode ser feita de forma dinâmica

Passos para Invocação Estática

Definição da classe de objetos usando IDL;

Execução do arquivo IDL através de um compilador

Adicionamento do código de implementação para o skeleton

Compilação do código

Ativação das definições da classe através do Repositório de Interfaces

Instanciação do objeto no servidor

Registro em tempo de execução do objeto no Repositório de Interfaces.

Invocação Dinâmica

Caracterizam-se por permitir que programa/clientes possam dinamicamente construir e invocar requisições a objetos.

Todas as informações necessárias para que o cliente possa realizar o processo de invocação, são encontradas no Repositório de Interfaces.

Surgiram da necessidade de se eliminar o problema que ocorria quando se necessitava inserir um novo objeto. Era preciso parar todo o sistema para que ele pudesse ser recompilado

Com as invocações dinâmicas é possível adicionar um novo objeto em tempo de execução sem a necessidade de parar o sistema para tal.

Interface de Invocação Dinâmica

DII – permite descobrir ou construir dinamicamente uma invocação a um objeto, permitindo a inclusão do mesmo sem que seja necessário um conhecimento prévio de quais objetos ou métodos estão disponibilizados.

O cliente não precisa utilizar o Stub, os parâmetros são todos checados em tempo de execução e não de compilação.

Para se executar esse tipo de invocação, é necessário:

Identificar o Objeto Alvo;

Pegar a interface do Objeto ;

Construir uma invocação ou chamada;

Invocar a requisição e receber o resultado (quando houver).

Interface de Invocação Dinâmica

Permite que o cliente realize operações de envio e recebimento de forma separada e também operações unidirecionais.

Um ponto de desvantagem da invocação dinâmica, é que acarreta um maior tráfego na rede, já que necessita realizar acessos adicionais ao Repositório de Interfaces, além do fato de que verificar os parâmetros em tempo de execução prejudica também um pouco o sistema.

Interface Skeleton Dinâmica

DSI - trabalha de forma similar ao DII, para os objetos servidores

Permite que novos objetos servidores sejam criados sem a necessidade de se usar os Skeletons

Funcionamento de uma DSI: o ORB passa a chamada ao DSI Essas chamadas possuem informações sobre o objeto

chamado e a operação solicitada Essas informações são acessadas no Repositório de

Interface e nos Adaptadores de Objetos.

Apesar de ser dinâmica, é capaz de receber invocações tanto estáticas como dinâmicas

Uma vantagem é que a DSI é muito útil para a implementação de pontes genéricas (um mesmo padrão) na ligação entre ORB’s.

IDL e Interfaces

Interface é um conjunto de informações dos objetos que são disponibilizadas aos demais

Utilizando para isso uma mesma linguagem (IDL)

Com a finalidade de permitir a interação de um conjunto de objetos de naturezas diferentes

Sem que seja necessário se preocupar com detalhes individuais da implementação de cada objeto.

IDL e Interfaces

Devem utilizar uma linguagem que seja puramente declarativa, gerando apenas declarações e não códigos

IDL - é a linguagem adotada pela OMA para especificar toda a sintaxe de todas as interfaces

Repositório de Interfaces

É utilizado pela IDL para armazenar todas as definições dos objetos

Deve estar sempre disponível tanto ao cliente como ao ORB e às implementações

permite a descoberta das informações de tipo em tempo de execução

É um excelente suporte para as invocações dinâmicas

Adaptador de Objetos

Faz o papel intermediário na comunicação entre os objetos e o ORB, ajudando na entrega de requisições às implementações dos objetos e na ativação desses objetos

Necessário devido a grande diversidade de implementação de objetos.

Serviços Oferecidos: Registros de Implementações de Objetos : utilizado na

localização da implementação do objeto Geração de Referência a Objetos Capacidade de Invocações(em auxílio com o Skeleton) Ativar ou Desativar uma Implementação de Objeto Segurança das Interações: junto com o ORB deve

garantir a entrega das requisições por meio de conexões múltiplas sem bloquear nenhuma dessas conexões.

Adaptador de Objetos

BOA (Basic Object Adapter): Adaptador de objetos genéricos, incluso na especificação CORBA.

Podem ser desenvolvidos adaptadores especializados para determinada especificação.

Os adaptadores especializados seriam apenas complementares ao BOA, realizando pequenas tarefas. Porém, acabaram por ser utilizados também para suprir as deficiências do BOA.

Funcionamento do Adaptador de Objetos

O ORB recebe uma requisição para um objeto e verifica se o servidor esta ativo ou não;

Ativa o servidor, caso não esteja, e passa para o mesmo todas a informações necessárias para a comunicação com o BOA;

O servidor envia uma mensagem para o BOA comunicando que está tudo pronto para interagir com ele;

O BOA passa a referência ao objeto para a rotina de ativação do objeto desejado, para que seja possível a sua ativação pelo servidor;

O BOA passa a invocação para o objeto, utilizando-se do Skeleton, e no momento que receber a resposta, a repassa para o cliente;

Funcionamento do Adaptador de Objetos

Se o BOA receber algumas chamadas adicionais sobre esse determinado objeto, ele (BOA) passará novas invocações ao objeto, entretanto o BOA pode receber novas chamadas, mas agora para um outro objeto, nesse caso ele precisará passar a referência ao objeto para a rotina de ativação do objeto, o servidor ativa esse objeto e depois é feita a invocação a esse outro objeto;

O servidor pode precisar desativar um objeto, para isso ele envia uma mensagem ao BOA comunicando que o objeto "x" será desativado;

O servidor pode também precisar se desativar, nesse caso, também enviará uma mensagem ao BOA comunicando-o do fato.

Adaptador de Objetos

De acordo coma especificação OMG, podem ser empregadas 4 políticas para a ativação de uma implementação de objeto pelo adaptador de objetos: Política Compartilhada de Servidor: permite que

objetos múltiplos possam ser executados no mesmo programa;

Política Não-compartilhada de servidor: objetos múltiplos não podem ser executados no mesmo programa;

Política de Servidor por Método: política onde um servidor é ligada toda vez que é recebida uma requisição;

Política de Servidor Persistente: o servidor fica sempre ativo.

Interoperabilidade

Com o avanço da tecnologia CORBA, foram surgindo no mercado ORB’s de diferentes fabricantes. Com isso, surgiu a necessidade de tratar a interoperabilidade entre esses ORB’s.

A questão não era apenas diferentes implementações dos ORB’s, mas também envolvia a segurança na comunicação e a disponibilização de um ambiente confiável de "teste" para os produtos que ainda estavam sendo desenvolvidos.

Interoperabilidade

CORBA 2.0: criação de domínios.

Um determinado objeto pode fazer parte de mais de um domínio, desde que satisfaça a todos os seus requisitos.

Limite de um domínio: limite de um escopo no qual uma determinada característica tem algum significado.

Como exemplos de domínios, podemos citar os escopos: de uma referência de objetos; de uma sintaxe de transferência de mensagens; de um endereço; de uma mensagem de rede; de uma política de segurança; de um identificador de tipos; de um serviço de transações qualquer, etc.

Interoperabilidade só será possível através de uma perfeita conexão de domínios.

Pontes

Fazem a conexão entres os objetos de diferentes domínios.

Devem ser capazes tanto de fazer a comunicação de domínios que se baseiam em uma mesma implementação quanto domínios que se baseiam em implementações diferentes.

Podem trabalhar de duas maneiras: Imediata(Direta) ou Mediada (Indireta).

Pontes Imediatas(Diretas)

Boa velocidade de comunicação

Menos geral, pois as requisições são transformadas diretamente da forma interna de um ORB para a forma interna do outro, daí o nome Diretas.

Pontes Mediadas(Indiretas)

Há um tradutor na extremidade de cada domínio

A requisição, através do tradutor do ORB, é traduzida da forma interna do ORB que a está transmitindo para um padrão comum entendido por todos os tradutores da rede.

Após a tradução, a requisição é enviada até o tradutor do ORB destinatário, onde o mesmo irá traduzir desse padrão comum para a forma interna de seu ORB.

Mais lenta que a Ponte Imediata.

Pontes

Além dessas duas classificações para a forma de comunicação entre os domínios, ainda podem ser aplicadas mais duas:

Ligações em Linha: quando são implementadas do interior do ORB. Pode ser feita por meio de um requerimento ao ORB para o fornecimento de serviços adicionais, ou por meio de introdução de códigos adicionais no stub e skeleton.

Ligações de Nível de Requisição: quando são implementadas em camadas superiores ao ORB.

GIOP

Para que as pontes se tornassem operáveis, foi especificado GIOP (General Inter-ORB Protocol), um padrão que atende às premissas (especificando formato das mensagens e uma representação comum para os dados) e permite a interligação ORB-para-ORB, além de ser capaz de trabalhar sobre qualquer protocolo de transporte.

Foi adotado o TCP/IP como protocolo de transporte padrão. Com isso surgiu o IIOP (Internet Inter-ORB Protocol).

IIOP

Especifica como as mensagens de padrão GIOP são transmitidas por meio de uma rede TCP/IP.

O IIOP possibilita o uso da própria internet como backbone entre os ORB’s.

O IIOP provê interoperabilidade também entre ORB’s compatíveis ao padrão CORBA.

A especificação de interoperabilidade da OMG definiu também o ESIOP (Environment-Specific Inter-ORB Protocol), como um conjunto de protocolos que permitem a interoperabilidade entre implementações baseados em GIOP, mas que utilizam protocolos proprietários de transportes.

Segurança

São implementados alguns serviços para garantir a segurança da transmissão das requisições, a saber:

Segurança - Autenticação

Identificador único, que permite ao cliente acessar qualquer servidor em qualquer lugar.

A autorização se procede a partir de um simples logon, que pega a autenticação e lhe oferece um conjunto de opções de segurança para a comunicação.

Para uma maior segurança, nenhum password é armazenado no login script do cliente.

Após feita a autenticação de um cliente em um determinado ORB da rede, o mesmo (ORB) se encarrega de propagar a autenticação por todo o resto da rede.

Segurança - Autorização

Após feita a autenticação do cliente, os servidores de objetos ficam encarregados de verificar quais operações podem ser feitas por aquele determinado cliente.

Para tal, os servidores usam as ACLs que contém uma lista de nomes e suas respectivas operações que podem ser executadas pelos mesmos.

É possível implementar várias políticas de ALC, podendo ser implementadas tanto pelo ORB como pelos servidores de objetos.

Segurança – Audit, Criptograia, Non-Reputdiation

Audit Serviço que monitora todos os eventos que

ocorrem no ORB, incluindo logons de clientes, quais objetos estão sendo usados e com quais servidores.

Considerado como parte fundamental na segurança, pois tem a capacidade de detectar possíveis intrusos.

Criptografia

Non-Reputdiation "guardas eletrônicos" que protegem todas as

partes no sistemas de possíveis falsos pedidos de requisições.

Vantagens na utilização de CORBA

Vantagens na utilização de CORBA, e outras arquiteturas de objetos distribuídos Os programadores não precisam mais se

preocupar com os detalhes de programação de baixo nível de rede, já que o nível de aplicação desse protocolo é apresentado como métodos de objetos definidos pela IDL, que apresenta-se mapeado para todos os propósitos;

Como o próprio nome já nos mostra, essa arquitetura absorve todos os conceitos de orientação a objetos existentes;

Com a utilização de applets, é possível acessar diretamente o conteúdo desejado, não necessitando assim de um browser intermediário na comunicação;

Vantagens na utilização de CORBA

A utilização de múltiplos threads permite a elaboração de ricas apresentações e possibilita aos servidores web atenderem vários clientes ao mesmo tempo;

O cliente pode criar um objeto e pedir que o mesmo referencie o servidor, sem precisar verificar no mesmo se algum evento ocorreu. Assim, o servidor apenas chamará o cliente quando o evento ocorrer.

A arquitetura CORBA utiliza o JAVA para acessar

os clientes web.

Implementações CORBA

ORBIX

http://web.progress.com/en/orbix/

VisiBroker

http://www.microfocus.com/products/visibroker/

Referências

http://www.gta.ufrj.br/grad/00_2/corba/

http://www.corba.org/

http://www.omg.org