Sistemas de Informação Distribuídos/Interoperação/Common Object Request Broker Architecture (CORBA)

Origem: Wikilivros, livros abertos por um mundo aberto.

Introdução[editar | editar código-fonte]

Utilização da IDL com duas linguagens diferentes

O CORBA é um padrão criado pelo OMG (Object Management Group) para permitir a interação entre aplicações heterogêneas em ambientes também heterogêneos, o que pode ser entendido como permitir a interação entre aplicações desenvolvidas em diversas linguagens de programação que estão sendo executadas em diferentes máquinas (também heterogêneas) conectadas a uma rede de dados.

Para possibilitar a heterogeneidade de aplicações, o CORBA agrega ao código da aplicação diversas informações sobre o código em si e sobre como ele pode/deve ser acessado, formando uma aplicação CORBA. Para especificar como este código pode ser acessado, é utilizada uma IDL (Interface Definition Language), uma linguagem para definição da interface que permite padronizar as chamadas aos métodos CORBA.

Com isso CORBA cria um cenário onde todas as chamadas feitas a métodos CORBA são padronizadas, necessitando apenas de um mapeamento dessa interface para a linguagem de programação utilizada para implementação do código. Diversos mapeamentos padrões foram criados para linguagens como C, C++, Lisp, Java, COBOL, Python, entre outras.

Interação entre componentes do CORBA para criação das aplicações

A figura acima ilustra o uso da IDL com algumas linguagens de programação. O caminho em vermelho mostra uma possível interação entre uma aplicação desenvolvida em C++ e uma outra desenvolvida em Python.

Além do encapsulamento das aplicações, o CORBA também especifica toda a arquitetura da comunicação entre estas aplicações e define diversos serviços que são necessários (ou desejáveis) no processo, como segurança e uso de transações.

A imagem à direta mostra um exemplo dos passos e componentes envolvidos na criação de uma aplicação do cliente e do servidor para comunicação usando CORBA.

Inicialmente, é criada a descrição da interface (IDL) da aplicação. Um compilador IDL criará dois componentes: o stub do cliente e o skeleton do servidor, cada um deles na linguagem de programação escolhida, que não é necessariamente a mesma para os dois (no exemplo da imagem são chamadas de linguagem 1 e 2). Utilizando esses componentes, o código da aplicação cliente (ou servidora) e a biblioteca do ORB que será utilizado, o compilador da linguagem gera a aplicação cliente (ou servidora) em código de máquina, pronta para ser executada. Estas aplicações se utilizam seus ORBs para se comunicar através de um canal de comunicação qualquer, usando um protocolo baseado no GIOP.

Esta imagem introduz diversos conceitos, como ORBs e GIOP, que serão comentados na próxima seção.

Componentes e conceitos[editar | editar código-fonte]

Stubs e skeletons

O uso típico de um stub e um skeleton para comunicação entre um cliente e um servidor através de uma rede..


Interface ORB


Compilador IDL


ORBs (Object Request Broker)

Um ORB é um componente intermediário da arquitetura do CORBA que facilita a comunicação entre o cliente e os objetos que implementam as funcionalidades que o cliente irá utilizar (objetos do servidor que são chamados de servants). Ele provê transparência de localidade para os clientes, separando os detalhes da invocação dos métodos remotos do código do cliente e permitindo assim que o cliente faça uma chamada remota da mesma forma que faria uma chamada local.

Este componente é responsável por encontrar e ativar o objeto que implementa o método solicitado, entregar a solicitação feita pelo cliente para o objeto e retornar as respostas da execução do método. O método solicitado pode ser implementado por um objeto localizado sob o mesmo ORB do cliente ou que esteja utilizando outro ORB. Portanto, os ORBs tem capacidade de se comunicar para trocar estas informações e manter a transparência da chamada aos métodos para o cliente (como pode ser visto na imagem ao lado, quando dois ORBs se comunicam utilizando protocolos como o IIOP).


Object Adapter


POA (Portable Object Adapter)

POA é um componente do lado do servidor na arquitetura CORBA. Ele auxilia o ORB na tarefa de entregar as requisições para os servants e tem como principal objetivo permitir a construção de aplicações servidoras portáveis entre diversas implementações de ORBs.

Entre as tarefas executadas por um POA, estão gerar e interpretar as referências aos objetos, ativar e desativar os servants e mapear as referências aos objetos para o servant correspondente.


CCM (CORBA Component Model)

CCM é uma definição introduzida com a versão 3.0 do CORBA que especifica como deve ser um framework de aplicação para os componentes CORBA.

CCM utiliza um container, aonde os componentes CORBA serão desenvolvidos, que disponibiliza diversos serviços utilizados por estes componentes, como persistência de dados, gerenciamento de transações, autenticação, entre outros. Isso reduz a complexidade de programação dos componentes, já que diversas funcionalidades necessárias já estarão inclusas no container.

Os componentes citados são as aplicações capazes de prover e aceitar serviços, sobre os quais o CMM cria uma abstração através de interfaces chamadas ports (assim como os beans representam uma abstração dos componentes no EJB). Como pode ser visto, o CCM é bastante semelhante ao modelo do Enterprise JavaBeans, porém ele não é restrito apenas à linguagem Java.


Interceptors

CORBA utiliza componentes intermediários chamados "portable interceptors" para mediar a comunicação. Três tipos de interceptors são especificados:

  • IOR, que são responsáveis pela criação de novas referências a métodos remotos;
  • Interceptors do cliente, que tratam as chamadas remotas no lado do cliente;
  • Interceptors do servidor, que tratam as chamadas remotas no lado do servidor.

Esses componentes também podem adicionar informações às mensagens que estão sendo transmitidas a fim de se comunicar com o interceptor que receberá estas mensagens.


GIOP (General InterORB Protocol)

O protocolo utilizado para comunicação entre ORBs do CORBA é o GIOP. Ele é um protocolo abstrato portanto não possibilita uma implementação direta, porém outros protocolos concretos foram especificados utilizando a base do GIOP, como o IIOP (Internet Inter-Orb Protocol), SSLIOP (SSL InterORB Protocol) e HTIOP (HyperText InterORB Protocol).

O mais notável é o IIOP, um protocolo que faz o mapeamento das mensagens GIOP e a camada TCP/IP, possibilitando a interação entre ORBs através da Internet.

A evolução da arquitetura e principais problemas[editar | editar código-fonte]

Esta seção fala sobre a evolução do CORBA ao longo dos anos e os principais problemas identificados na arquitetura.

Utilização hoje e considerações finais[editar | editar código-fonte]

Atualmente, sistemas CORBA são utilizados principalmente dentro de redes de empresas, isolados e protegidos do qualquer outro ambiente (da Internet, de outras redes).[1] Outras áreas onde o uso de CORBA ainda é importante são as áreas de sistemas embarcados e sistemas de tempo-real, onde alto desempenho é um fator fundamental.

O CORBA é uma arquitetura que teve um grande avanço e aceitação em suas primeiras versões, mas a empolgação inicial rapidamente acabou-se, tornando o CORBA não mais a principal tecnologia para comunicação entre processos atualmente.

Porém, apesar do CORBA ter se tornado uma tecnologia muito menos abrangente que o esperado, fontes afirmam que a arquitetura ainda é muito utilizada, ainda mais do que na época de seu crescimento nos anos 90. Como seus usuários incluem-se reservas aéreas, aplicações de back-end para e-commerce, transações entre empresas telefônicas e sistemas financeiros.[2]

Diversos problemas existentes na arquitetura foram comentados anteriormente e são citados em diversas fontes. Por outro lado, algumas fontes defendem o CORBA acusando os competidores de serem os principais críticos da arquitetura, mas ao mesmo tempo assumem que diversos dos problemas relatados são realmente verdadeiros.

Problemas, como a complexidade, são resultados dos objetivos extremamente abrangentes do CORBA, visando possibilitar a comunicação de aplicações em heterogêneas em ambientes heterogêneos e tratar todos os níveis desta comunicação, inferindo poucas restrições nestes conceitos. Apesar de todos esses problemas relacionados à complexidade que foram citados, alguns acreditam que o CORBA “é tão complexo quanto ele precisa ser”,[2] por possibilitar a construção de sistemas muito complexos sem remover opções do usuário.

É importante ressaltar que, sendo uma tecnologia utilizada atualmente ou não, o CORBA introduziu e utilizou conceitos muito importantes e todo o aprendizado adquirido com seus sucessos e falhas são de muito valor para a área.

História[editar | editar código-fonte]

Esta seção mostra em poucas linhas a evolução das especificações do CORBA, apresentando as principais melhorias e inovações incluídas em algumas versões:

1991 - 1993: CORBA 1.0 – 1.2

  • Introduziu o CORBA Object Model, núcleo básico de APIs, IDL;
  • Mapeamento apenas para a linguagem C.

1996 - 2001: CORBA 2.0 – 2.6

  • GIOP e IIOP;
  • Inclusão de segurança e suporte à transações;
  • Melhorias nos repositórios de interfaces;
  • Mapeamento Java, C++, Smalltalk.

2002: CORBA 3.0

  • Melhoria na integração com Java, maior facilidade de programação;
  • Atualmente na versão 3.0.2.

Implementações[editar | editar código-fonte]

Listas de implementações CORBA podem ser encontradas nos locais abaixo:

Links Externos[editar | editar código-fonte]

Bibliografia[editar | editar código-fonte]

  1. Henning, Michi. "The Rise and Fall of CORBA", ACM Queue, Volume 4, No.5, Junho, 2006.
  2. 2,0 2,1 "Response to 'The Rise and Fall of CORBA by Michi Henning'", OrbZone, Junho, 2006.