CORBA é uma arquitetura que estabelece e simplifica a troca de dados entre siste- mas distribuídos heterogêneos de forma transparente, não importando em qual lingua- gem de programação foi desenvolvida, nem o local onde está ou em qual plataforma ou sistema operacional esteja sendo executada.
O paradigma CORBA é uma combinação de duas metodologias existentes. A pri- meira delas é a computação cliente-servidor distribuída e a segunda é a programação orientada a objetos, onde um importante conceito deve ser entendido, o conceito de objetos. Para efeito de conhecimento, objetos são instâncias de classes, e essas clas- ses definem o comportamento dos objetos através de métodos e atributos. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens envi- adas a ele, assim como se relacionar e enviar mensagens a outros objetos que serão acessadas pelo cliente [6]. A figura 9 descreve uma visão geral de CORBA.
Figura 9: Visão Geral de CORBA
Interface Definition Language (IDL)
Descreve uma classe chamada interface que contém as implementações dos mé- todos a serem requisitados. Essa descrição de interface especifica o formato das chamadas das operações e também especifica os parâmetros de entrada e saída ne- cessários para que a operação seja executada.
Um exemplo do uso da IDL seria fornecer um método que retornasse o nome de um determinado usuário passando como parâmetro o seu respectivo código. Nessa
classe, existiria um método que teria como assinatura, ou seja, os parâmetros, o có- digo a ser localizado. Uma vez localizado o código, o que restaria seria o método retornar o nome do usuário relacionado ao código encontrado.
Object Request Broker (ORB)
A comunicação entre cliente e servidor é feita pelo ORB. Ele faz o intermédio entre cliente e objeto, permitindo que os objetos requisitados pelos clientes ao servidor façam e recebam requisições de métodos de forma transparente em um ambiente distribuído e heterogêneo. É responsável pela localização do objeto a qual se destina uma determinada requisição, como também, pelo envio dos parâmetros da requisição no formato aceito pelo objeto em questão, e responsável pela entrega da resposta do objeto chamado, ao cliente, como pode ser visto na figura 10.
Figura 10: Requisição de um cliente
O ORB permite o acesso distribuído às implementações de objetos através do re- positório de interfaces, onde ele coloca à disposição as interfaces públicas dos objetos especificados na IDL [6].
Invocação de um objeto
Um cliente acessa um objeto através da referência deste objeto e da requisição de operações executadas pelo mesmo. Como o cliente precisa ter contato apenas com a interface do objeto, a estrutura interna deste se mantém transparente. A transferência de controle de dados do cliente para o objeto e, em seguida, o retorno para o cliente, é de responsabilidade do ORB. Se a invocação não for realizada perfeitamente, o
ORB informa ao cliente que ocorreu uma exceção. Os clientes de um objeto podem fazer a invocação utilizando a técnica de stub, geradas na compilação da descrição de interface do objeto, ou um conjunto de rotinas para invocação dinâmica de objetos que podem ser utilizado [6].
Interface de invocação estática (Static Interface Invocation - SII)
Para acessar uma operação sobre um objeto, o cliente precisa chamar - e estar estaticamente ligado ao stub correspondente. A interface stub conduz o ORB direto para o domínio de programação da aplicação: o cliente interage com objetos servi- dores chamando suas operações como se houvesse chamado operações de objetos locais. Quando um desenvolvedor escreve seu código, ele determina quais stubs cada cliente contém, fazendo com que essa interface não possa acessar novos tipos de ob- jetos adicionados futuramente ao sistema [6].
Interface de invocação dinâmica (Dynamic Interface Invocation - DII)
A interface dinâmica é necessária quando a interface do objeto não pode ser co- nhecida a tempo de compilação. Em uma invocação dinâmica, o cliente especifica, através da DII, o objeto ao qual se destina a requisição, a operação solicitada e os parâmetros da operação através de uma seqüência de chamadas de rotinas de requi- sição. Como as implementações de objeto não conseguem detectar se uma determi- nada invocação chegou ao ORB, via invocação de interface estática ou invocação de interface dinâmica, o cliente fica inteiramente responsável pela escolha. O ORB ainda faz todo o trabalho, fazendo com que a requisição chegue de forma transparente para o objeto [6].
Interface dinâmica de esqueleto (Dynamic Skeketib Interface - DSI)
Na DSI, o receptor sabe que a requisição vem de um skeleton dinâmico ou está- tico, de forma transparente, ao contrário do que acontece na interface de invocação dinâmica. Ao invés de ser acessada através de um skeleton, que é específico para uma operação particular, uma implementação de objetos é alcançada através de uma interface que provê acesso aos nomes das operações e parâmetros de maneira aná- loga à interface de invocação dinâmica do lado do cliente. Os skeletons podem ser
invocados através de clientes stubs e através de interface de invocação dinâmica. Nos dois modos de invocação o resultado obtido será o mesmo [6].
Adaptador de objeto
Uma implementação de objetos acessa as funções do ORB através do adaptador de objetos. Cabe a ele fazer a ativação e desativação de implementações de objetos, manter o registro das implementações, promover a requisição de métodos e garantir a segurança da interação entre os elementos envolvidos na requisição da operação. A estrutura interna de um adaptador de objetos depende basicamente dos serviços dis- ponibilizados pelo núcleo ORB e dos outros requisitos das implementações de objeto às quais se destina [6].
Repositório de implementações
Local onde ficam armazenadas informações que permitem ao ORB localizar e ativar implementações dos objetos. Através de operações feitas no repositório de implementações é possível a instalação de implementações e políticas de controle relacionadas à ativação e execução de implementações de objetos.
Persistência
Ao contrário dos objetos tradicionais, os objetos em sistemas distribuídos possuem uma característica de dualidade: um estado dinâmico, tipicamente alocado em memó- ria volátil, e um estado persistente que não pode ser destruído após o encerramento do programa que os criou e que pode ser usado para reconstruir o estado dinâmico, devendo ser armazenado em memória não volátil. A arquitetura CORBA, para pro- ver a persistência, define o Persistent POS como sendo responsável por armazenar o estado persistente dos objetos, utilizando quatro elementos [6]:
1. Objetos Persistentes (Persistent Object);
2. Gerenciador de Objetos Persistentes (Persistent Objects Manager ); 3. Serviços de Persistência de Dados (Persistent Data Services); 4. Base de Dados (Datastores).