figura 1 - Um pedido através da ORB
A CORBA obedece um modelo de objeto "clássico", onde os clientes enviam mensagens para os objetos. Nesta secção apresentaremos os principais conceitos e definições da CORBA.
As definições aqui apresentadas são baseadas na segunda versão do documento The Common Object Request Broker: Architecture and Specification datado de Julho 1995
A figura 1 resume a forma como a implementação do
objeto é requisitada por um cliente. O cliente é qualquer objeto capaz de solicitar um serviço e a implementação do objeto
é a resposta. A combinação de código e dados caracterizam o comportamento de um
objeto clássico. A ORB é responsável por todos mecanismos necessários para:
- achar a implementação de objeto de um pedido,
- preparar a implementação de objeto para receber um pedido
- fazer toda a comunicação.
Esse processo é totalmente transparente ao cliente, não importando onde o objeto está localizado, em qual linguagem de programação foi implementado ou qualquer outro aspecto no que diz respeito a interface do
objeto e/ou a sua implementação.
figura 1 - Um pedido através da ORB
A figura 2 mostra a estrutura individual de uma (ORB). As interfaces para a ORB são mostradas pelas caixas listradas e as setas indicam se a ORB é chamada ou faz uma "up-call" através da interface.
figura 2 - estrutura da interface ORB
Para fazer um pedido (requisição), o cliente pode usar uma Interface de Invocação Dinâmica (independente da interface do objeto alvo) ou uma "OMB IDL (Interface Definition Language) stub".(stub específica, dependendo do objeto alvo) O cliente, pode então interagir diretamente com a ORB em algumas funções.
A Implementação de Objeto recebe uma requisição como "up-call" através do esqueleto da OMG IDL ou do esqueleto dinâmico. A Implementação do Objeto chama o Adaptador de Objeto e a ORB durante o processamento ou depois.
A definição de interface para objetos pode ser feita de duas maneiras. Pode ser definida como estática através da OMG IDL (Interface Definition Language). Esta linguagem define o tipo de objetos de acordo com as operações que serão realizadas por eles e os parâmetros usados para estas operações. Alternativamente, as interfaces podem ser adicionadas (colocadas) em um Repositório de Interface, isto representa o componente de uma interface como objeto, permitindo acesso a estes componentes em tempo de execução. Em qualquer implementação de ORB, a IDL e o Repositório de Interface tem o mesmo peso.
O cliente faz uma requisição tendo acesso a uma referência de objeto e sabendo o tipo deste objeto e a operação que será realizada. O cliente começa a requisição chamando um stub especifico para aquele objeto ou construindo uma requisição dinamicamente.(veja figura 3)
figura 3 - Cliente usando um stub ou uma interface dinâmica de invocação
Tanto o stub quanto a interface dinâmica satisfazem a mesma semâtica de requisição e o receptor da mensagem não pode dizer como a requisição foi feita.
A ORB localiza uma implementação de código desejado, transmite os parâmetros e transfere o controle da Implementação de Objeto através de um esqueleto IDL ou um esqueleto dinâmico. (veja figura 4)
figura 4 - .Uma implementação de Objeto recebendo um pedido
Esqueletos são específicos para cada interface e adaptador de objeto. Na realização de um pedido, a implementação do objeto pode obter alguns serviços da ORB através do adaptador de objetos. Quando o pedido é completado, controles e valores de saída são retornados ao cliente.
A Implementação de Objeto pode escolher qual Adaptador de Objeto usar. Esta decisão é baseada em que tipo de serviço a Implementação de Objeto requer.
A figura 5 mostra como interface e informações de implementação são disponibilizadas para o Cliente e para a Implementação de Objetos. A interface é definida pela OMG IDL e/ou pelo Repositório de Interface; a definição é usada para gerar os Stubs Cliente e os esqueletos de Implementação de Objetos.
figura 5 - Repositórios de Interface e Implementação
A Implementação de Objeto é fornecida durante a instalação e é armazenada no Repositório de Implementação para ser usada durante a entrega dos pedidos.
A arquitetura de uma ORB é definida pelas suas interfaces. Qualquer implementação que satisfaça a interface apropriada é aceitável.
A interface é organizada em 3 categorias:
Talvez existam várias implementações de ORB que possuam diferentes representações para objetos e diferentes maneiras de realizar invocações. Isto pode ser possível para um cliente que possua acesso simultâneo a duas referências de objetos comandadas por diferentes ORBs. Quando duas ORBs são colocadas para trabalhar juntas, elas tem que estar capacitadas para distinguir suas referências de objetos. Não é responsabilidade do cliente se preocupar com isto.
A "ORB Core" é a parte da ORB que provê a representação básica de objetos e a comunicação dos pedidos CORBA, é desenvolvido para suportar diferentes mecanismos de objeto, e isto é conseguido pela estrutura da ORB com componentes acima da "ORB Core", que provêem interfaces que podem mascarar as diferenças entre "ORB Cores".
O cliente de um objeto tem acesso a referência de objeto do objeto, e chama a operações do objeto. O cliente sabe apenas a estrutura lógica do objeto de acordo com sua interface e experiências do comportamento do objeto através das invocações. Contudo nós vamos genericamente considerar o cliente como sendo um programa ou processo fazendo pedidos a um objeto, isto é importante para determinarmos quem é cliente de um determinado objeto. Para complicar as coisas, por exemplo, a implementação de um objeto pode ser cliente de outro objeto.
Geralmente clientes vêem objetos e interfaces de ORB através da perspectiva de mapeamento de linguagem, trazendo a ORB diretamente para o nível de programação. Clientes são totalmente portáveis e tem que ser capazes de trabalhar sem problemas com mudanças em qualquer ORB que suporte a linguagem de mapeamento determinada com qualquer objeto que implemente a interface desejada. Clientes não possuem qualquer conhecimento da implementação de objeto, que adaptador de objeto é usado para a implementação ou que ORB é usada para fazer o acesso.
A implementação de objeto provê a semântica do objeto, geralmente feita pela definição de dados para o objeto e códigos para os métodos de objeto. Frequentemente a implementação irá usar outros objetos ou softwares adicionais para implementar o comportamento do objeto.
Uma variedade de implementações de objetos podem ser superpostas, incluindo servidores distintos, bibliotecas, programas por método, aplicações encapsuladas, banco de dados orientados à objeto, etc. Através do uso de adaptadores de objetos adicionais, é possível suportar virtualmente qualquer estilo de implementação de objetos.
Geralmente, implementações de objetos não dependem da ORB ou como o cliente chama o objeto. A implementação de objeto pode selecionar interfaces para serviços dependentes da ORB pela escolha do adaptador de objeto.
Uma referência de objeto é a informação necessária para especificar um objeto dentro da ORB. Clientes e implementação de objeto têm uma noção vaga da referência de objeto de acordo com o mapeamento de linguagem. Duas implementações de ORB podem diferir na escolha da representação da referência de objetos.
A representação de uma referência de objeto direcionada para um cliente é válida apenas durante o tempo de vida do cliente.
Todas ORBs possuem a mesma linguagem de mapeamento à uma referência de objeto para uma linguagem de programação particular. Isto permite que um programa escrito em uma linguagem particular acesse uma referência de objeto independente da ORB. A linguagem de mapeamento possui caminhos adicionais para acessar referência de objetos de acordo com a conveniência do programador.
A linguagem de definição de interface da OMG define os tipos de objetos pela especificação de suas interfaces. Uma interface consiste de uma série de operações e de parâmetros para estas operações. Note que, apesar da IDL possuir a composição (estrutura) conceitual para descrição de objetos manipulados pela ORB, não é necessário existir um código IDL fonte para a ORB trabalhar. Enquanto a informação equivalente estiver disponível em forma de rotinas stub ou em repositório de interface a tempo de execução, a ORB pode estar disponível para funções corretamente.
IDL é a forma pela qual uma implementação particular de objeto diz aos clientes em potencial quais operações estão disponíveis e como elas podem ser chamadas (invocadas). Através da definição da IDL, é possível mapear objetos CORBA em linguagem de programação particular ou em objetos de sistema.
Diferentes linguagens de programação, orientadas à objetos ou não, podem acessar os objetos CORBA por diferentes caminhos. Para linguagens orientadas à objeto, pode ser desejável ver os objetos CORBA como objetos de uma linguagem de programação. Até mesmo para linguagens de programação não orientadas a objeto isto é uma boa idéia para esconder a exata representação de uma referência de objeto da ORB, o nome dos métodos, etc. Um mapeamento particular da OMG IDL por linguagem de programação tem que ser o mesmo para todas as implementações da ORB. Linguagem de mapeamento inclui a definição da linguagem específica dos tipos de dados e a interface das procedures para acessar objetos através da ORB. Isto inclui a estrutura da interface stub client, a interface dinâmica de invocação, a implementação do esqueleto, o adaptador de objeto e a interface ORB.
A linguagem de mapeamento também define a interação entre a invocação de objetos e a linha de controle na implementação do cliente. O mapeamento mais comum provê chamadas síncronas, em que a rotina retorna quando a operação com o objeto é completada. Mapeamentos adicionais podem ser providos para permitir que a chamada seja iniciada e o controle retorne para o programa. Em alguns casos adicionais, rotinas de linguagem específica podem ser usadas para sincronizar as linhas de controle do programa, com a invocação do objeto.
Para o mapeamento de linguagens não orientada à objeto, existirá uma interface de programação de stubs para cada tipo de interface. Geralmente, o stub apresenta acesso para o OMG IDL - operações definidas num objeto em que o caminho é fácil para programadores predizerem, uma vez que eles são familiarizados com a OMG IDL e a linguagem de mapeamento por linguagem de programação particular. O stub faz chamada no resto da ORB usando interfaces que são privadas e optimizadas para uma "ORB Core" particular. Se mais de uma ORB estiver disponível, teremos diferentes stubs correspondendo a diferentes ORBs. Neste caso é necessário para a ORB e para a linguagem de mapeamento cooperarem, associando os stubs corretos com a referência de objeto particular.
Linguagens de programação orientadas à objeto, como C++ e Smalltalk, não necessitam da interface stub.
A interface está também disponível para permitir a construção dinâmica de invocações à objetos, isto é, ao invés da chamada a rotina stub ser específica para uma operação particular de um objeto particular, o cliente pode especificar o objeto a ser invocado, a operação através de uma chamada ou uma série de chamadas. O código cliente pode conter informações sobre a operação a ser realizada e os tipos de parâmetros à serem passados (estes são obtidos do repositório de interface ou de outra fonte em tempo de execução).
A natureza de uma interface de invocação dinâmica pode variar substancialmente de uma linguagem de programação de mapeamento para outra.
Para uma linguagem de programação particular e possivelmente dependendo do adaptador de objeto, haverá uma interface para métodos, que implementam cada tipo de objeto. A interface geralmente será uma interface "up-call", nela a implementação do objeto escreve rotinas que obedecem a interface e a ORB às chamam através do esqueleto.
A existência do esqueleto não implica na existência de uma stub cliente correspondente (clientes podem fazer requisições usando a interface dinâmica de invocação).
É possível escrever um adaptador de objeto que não use esqueletos para invocar os métodos de implementação. Por exemplo, é possível usarmos implementações dinâmicas para linguagens como a Smalltalk.
Existe uma interface que permite construção dinâmica de invocações a objetos. Isto é, ao invés de serem acessados através do esqueleto, que é específico para uma determinada operação, a implementação de objeto é feita através de uma interface que prove acesso ao nome da operação e parâmetros, de maneira análoga ao lado cliente da Interface de Invocação Dinâmica. Para determinarmos os parâmetros é necessário apenas o conhecimento estático destes ou conhecimento dinâmico (obtido através do Repositório de Interface).
O código da implementação deve ter descrições de todos parâmetros de operações da ORB, e a ORB deve prover os valores de qualquer parâmetro de entrada usado na operação. O código de implementação fornece os valores de qualquer parâmetro de saída ou excessão, para o ORB, depois da operação ser concluída. A natureza do esqueleto de invocação dinâmica varia de acordo com a linguagem de programação de mapeamento ou de acordo como o adaptador de objeto, mas geralmente é uma interface "up-call".
Esqueletos dinâmicos podem ser invocados tanto através de stubs cliente como através de interface dinâmica de invocação; qualquer tipo de interface de requisição cliente fornece os mesmo resultados.
Um adaptador de objeto é o primeiro caminho que uma ORB fornece para serviço de acesso a implementação de objetos. Existem diversos adaptadores de objetos disponíveis, com interfaces específicas para cada tipo de objetos. Serviços fornecidos pela ORB através de adaptadores de objetos incluem: geração e interpretação de objetos, referência de mapeamento de objetos para implementações e implementações de registro.
A diversidade das características (propriedades) de um objeto, torna difícil a "ORB Core" fornecer uma única interface conveniente e eficiente para todos objetos. Contudo, através de adaptadores de objetos, é possível que a ORB atenda a um grupo particular de implementação de objetos que possuam características similares com interfaces específicas para elas.
A interface ORB é a interface que vai direto à ORB e é a mesma para todas ORBs, não dependendo da interface do objeto nem do adaptador de objeto. A maioria das funcionalidades da ORB são fornecidas através dos adaptadores de objeto, stubs, esqueletos ou invocações dinâmicas e por isso existem apenas algumas operações que são comuns a todos os objetos. Essas operações são úteis para clientes e implementações de objetos.
É o serviço que fornece objetos que representam informações da IDL, disponíveis a tempo de execução. A informação do repositório de interface é usada pela ORB para realizar uma requisição. E mais, usando estas informações, é possível que o programa encontre objetos em que a interface era desconhecida quando da compilação. Agora, é possível determinar que operações são válidas para este objeto e invocá-lo.
O repositório de interface é um lugar para guardar informações adicionais, associadas a interfaces de objetos ORB.
Contém informações que permitem que a ORB localize e ative as implementações de objetos. Embora a maioria das informações do repositório de implementação seja específica de uma ORB ou de um ambiente de operação, o repositório de implementação é um lugar conveniente para se gravar certas informações. Geralmente, a instalação de implementações e controle de políticas relacionadas com a ativação e execução da implementação de objeto são através de operações no repositório de implementação.
O repositório de implementação é um bom lugar para guardar informações adicionais, associadas com a implementação de objetos ORB.