CORBA - Common Object Request Broker

Architecture
Rafael Vasconcelos do Nascimento
Gilvan Antonio dos Santos Filho
Universidade Federal do Acre
Curso de Sistemas de Informação
{rafaelvasconn, gilvan.sfilho}@gmail.com

Introdução

Atualmente, novos sistemas ou aplicações são criados pela conexão de componentes de

software já existentes, que podem ter sido previamente desenvolvidos ou adquiridos, ou podem
estar ainda em desenvolvimento. Apesar da integração ser muitas vezes considerada mais simples
que um novo desenvolvimento, ela não tem se mostrado mais rápida nem mais barata. Alguns dos
desafios inerentes a esse modelo são a necessidade de customizar interfaces para componentes
que não foram projetados para trabalhar juntos e a necessidade de comunicação através de
plataformas de hardware heterogêneas.
Considerando a heterogeneidade de plataformas computacionais e de sistemas
operacionais presentes nas grandes redes cooperativas e da Internet, a visão de uma aplicação
deve considerar a possibilidade de utilização de componentes (ou objetos) concebidos nas
diferentes linguagens e capazes de serem executados em diferentes ambientes (COULOURIS,
1998).
Middleware é o termo que se aplica a uma camada de software que fornece uma abstração
assim como o mascaramento da heterogeneidade das redes, do hardware, de sistemas
operacionais e de linguagens de programação. Além disso, o middleware fornece um modelo
computacional uniforme para ser usado pelos programadores de serviços e de aplicativos
distribuídos.
O CORBA (Commom Object Request Broker) é um exemplo de Middleware que mascara
a heterogeneidade das linguagens de programação entre os aplicativos distribuídos.
Corba
O CORBA é um projeto de midleware que permite as aplicações se comunicarem umas
com as outras independentemente de suas linguagens de programação, de suas plataformas de
hardware e software , das redes pelas quais se comunicam e de seus desenvolvedores.
As aplicações são contruidas a partir de objetos CORBA, os quais implementam
interfaces determinadas pela linguagem de definição de interface, IDL (Interface Description
Language), do CORBA. Os clientes acessam acessam os métodos dos dos objetos CORBA por
meio de RMI (Remote Method Invocation). O componente de middleware que suporta RMI é
chamado de Object Request Broker (Agente de requisição de objeto) ou ORB.
O Object Management Group (OMG),um consórcio de empresas que iniciou em 1989,
inventou o CORBA, o qual em si, é simplesmente urn padrão. Produtos compatíveis com
CORBA implementam a especifìcação deste. Além do CORBA, a OMG definiu um protocolo
chamado Internet Inter-ORB Protocol (IIOP). O IIOP é o protocolo de Internet padräo para o
CORBA. Você nunca o vê; ele é utilizado nos bastidores para comunicações de objetos
distribuidos.
Programar em um sistema RMI de múltiplas linguagens, como o RMI CORBA, exige
mais do programador se comparado com o desenvolvimento em um sistema RMI de linguagem
única, como o RMI do Java. Os seguintes novos conceitos precisam ser aprendidos: o modelo de
objeto oferecido pelo CORBA; a linguagem de definição de interface e seu mapeamento para a
linguagem de implementação.
O modelo de objeto do CORBA é semelhante à descrição ao modelo de objeto distribuído
em COULOURIS (1998), mas clientes não são necessariamente objetos – um cliente pode ser
qualquer programa que envie mensagens de requisição para objetos remotos. Assim, um objeto
CORBA implementa uma interface IDL, tem uma referência de objeto remoto e é capaz de
responder às invocações de métodos em sua interface IDL. Como as linguagens de
implementação terão diferentes noções de classes, ou mesmo nenhuma noção, o conceito de
classe não existe no CORBA. Portanto, classes não podem ser definidas na IDL do CORBA, o
que significa que instâncias de classes não podem ser passadas como argumentos. Entretanto,
estruturas de dados de vários tipos e complexidade arbitrária podem ser passadas como
argumento.
 IDL – Interface Definition Language

A IDL pode ser vista como o mais significativo elemento de CORBA, pois consiste de
uma notação aplicável universalmente para API’s – Application Program Interfaces. Ela faz a
ligação entre o código do cliente e as implementações e/ou serviços do objeto.
A IDL é independente de linguagem, suportando múltiplas amarrações de linguagem a
partir de uma única especificação. Sendo assim, interfaces de software precisam ser escritas
apenas uma vez.
A linguagem também é independente de plataforma. Uma interface assim especificada se
mostra consistente com qualquer ORB (Object Request Broker) e plataforma. Seu uso evita,
portanto, que se encontrem problemas de portabilidade de plataforma, que podem ser
provenientes de sistemas operacionais e interfaces definidades pelo fabricante.
Deve-se salientar, também, que IDL é puramente uma especificação. Não há restrições
quanto a implementações do objeto que define as interfaces, baseado em CORBA. Essas
implementações podem utilizar qualquer linguagem e tipo de algoritmo, que ficam escondidos
dos clientes que utilizam a interface. Essa separação é uma das grandes vantagens da abordagem
de CORBA, pois garante a reusabilidade e a redução da necessidade de construção de software.
Na IDL, cada parâmetro é marcado como sendo de entrada, saída ou ambos, usando-se as
palavras-chaves in, out, inout.

module Matematica{
exception DivisaoPorZero{
float arg1;
float arg2;
};
interface Calculadora{
float soma (in float arg1, in float arg2);
float divisao (in float arg1, in float arg2)
raises (DivisaoPorZero);
};
};

Figura 1. Interface IDL

 ORB

O papel do ORB (agente de requisição de objeto – object request broker) é unificar o

acesso a serviços da aplicação, através de um mecanismo comum de chamada remota de
procedimento (RPC – Remote Procedure Call) orientado a objeto. A separação de interface e
implementação é o que permite a unificação de acesso a recursos.
O ORB funciona como uma infraestrutura para comunicação entre diferentes módulos de
software. O objeto cliente faz uma requisição de serviço invocando operações ao ORB, que
garante uma independência de comunicação, separando não apenas o cliente e a implementação
um do outro, mas também ambos da infraestrutura de comunicação e protocolo. Assim, o
protocolo pode ser substituído sem prejuízo à aplicação, o que dá flexibilidade para as
arquiteturas de aplicações e simplifica o modelo de computação distribuída.

Arquitetura CORBA

A arquitetura é projetada para suportar a função de um agente de requisição de objeto

(ORB) que permite aos clientes invocarem métodos em objetos remotos, onde clientes e
servidores podem ser implementados em uma variedade de linguagens de programação.

cliente servidor

Figura 2. Os principais componentes da arquitetura CORBA.

A Figura 2 mostra os principais componentes da arquitetura CORBA, e comparando-a

com a arquitetura RMI podemos notar que a arquitetura CORBA contém três componentes
adicionais: o adaptador de objeto, o repositório de implementações e o repositório de interfaces.
 O CORBA fornece invocações estáticas e dinâmicas. As invocações estáticas são usadas
quando a interface remota do objeto CORBA é conhecida no momento da compilação.
Basicamente, a função do Núcleo ORB é executar o protocolo requisição-resposta entre o
cliente e o servidor. Além disso, um núcleo ORB fornece uma interface que inclui: operações que
o permitem ser iniciado e parado; operações para fazer a conversão entre as referências de objeto
remoto e strings; operações para fornecer listas de argumentos para requisições usando invocação
dinamica.
A função de um adaptador de objeto é fazer a ligação entre objetos CORBA com
interfaces IDL e as interfaces da linguagem de programação das classes serventes
correspondente. Um adaptador de objeto tem as seguintes tarefas:
• Criar referências de objeto remoto para objetos CORBA;
• Enviar cada RMI, por meio de um esqueleto, para o servente apropriado;
• Ativar e desativa serventes.
Um adaptador de objeto fornece para cada objeto CORBA um nome de objeto exclusivo,
o qual faz parte de sua referência de objeto remoto. O mesmo nome é usado sempre que o objeto
é invocado. O nome do objeto pode ser especificado pela aplicação ou gerado pelo adaptador de
objeto.
O padrão CORBA 2.2 para adaptador de objetos é chamado Portable Object Adapter
(POA). É chamado portável porque permite que aplicações e serventes sejam executados em
ORBs produzidos por diferentes desenvolvedores. O POA permite que objetos CORBA sejam
instanciados de forma transparente e, além disso, ele separa a criação de objetos CORBA da
criação de serventes que implementam esses objetos.
As classes de esqueleto são geradas na linguagem do servidor por um compilador de IDL.
As invocações de métodos remotas são enviadas por meio do esqueleto apropriado para um
servente em particular e o esqueleto desempacota os argumentos nas mensagens de requisição e
empacota exceções e resultados nas mensagens de resposta.
Os Stubs e Proxies são gerados na linguagem do cliente por um compilador IDL, e
empacota os argumentos nas requisições de invocação e desempacota exceções e resultados nas
mensagens de resposta.
Um repositório de implementações é o responsável por ativar servidores registrados sob
demanda e por localizar os servidores que estão correntemente em execução. Ele armazena um
mapeamento dos nomes de adaptadores de objeto para nomes de caminho de arquivos contendo
implementações de objeto.
O Repositório de Interfaces é o responsável por fornecer informações sobre as interfaces
IDL registradas para clientes e servidores que as exigirem. Para uma interface de determinado
tipo, ele pode fornecer nomes dos métodos e, para cada método, os nomes e tipos dos argumentos
e exceções. Assim, o repositório adiciona um recurso de reflexão no CORBA.

APLICAÇÃO

O CORBA pode ser usado para integração de legados. Se já tivermos um investimento

(como urna aplicação de operações bancárias legadas), atualmente poderá alavancá-lo utilizando
o CORBA. Por exemplo, digamos que você tenha urna aplicação de operações bancárias escrita
em C++. O CORBA fornece a capacidade de preservá-la e reutilizá-la. Você pode empacotar o
investimento existente corno urn objeto CORBA, permitindo que ele seja chamado a partir de
qualquer aplicação. O CORBA é urn padrão neutro quanto à linguagern e permite que códigos
escritos em várias linguagens se comuniquem. Portanto, ele é urna plataforma ideal para a
cooperação entre códigos escritos em linguagens diferentes.
EJB ou Enterprise JavaBeans é um dos principais componentes da plataforma J2EE (Java
2 Enterprise Edition). É um componente do tipo servidor que executa no container do servidor de
aplicação. Os principais objectivos da tecnologia EJB são fornecer um rápido e simplificado
desenvolvimento de aplicações Java baseado em componentes distribuídas, transacionais, seguras
e portáveis.
O CORBA e o EJB têm ganchos que os conectam. Alguns produtos de EJB permitem que
seus enterprise beans sejam chamados a partir de dois tipos diferentes de clientes: os escritos para
utilizar o conjunto J2EE de APIs e os escritos para utilizar as APIs do CORBA. Isso significa que
o código escrito em C+ + ou Smailtalk pode chamar seus enterprise beans.

Referências
AMBLER, Scott W.; ROMAN, Ed; KINDBERG, Tim. Dominando
Enterprise Javabeans. 2. ed. São Paulo: Bookman, 2004. 511 p.