figura 1 - Um pedido através da ORB
Universidade Federal do Rio de Janeiro
Escola de Engenharia - Departamento de Eletrônica e Computação
Disciplina: Redes de Computadores I - Professor: Otto
Tema do trabalho: CORBA -
por Alessandro Martins[
Sobre o trabalho] [Motivação] [Introdução] [Conceitos] [Interoperabilidade]
Este trabalho faz parte da disciplina de Redes de Computadores I, cursada no segundo semestre de 1999 em caráter optativo segundo o currículo (antigo) do curso de Engenharia Eletrônica da UFRJ. Ele será apresentado em duas partes, a primeira em html ( nas páginas que se seguem ) e a segunda na forma oral, num pequeno seminário de aproximadamente 20 minutos, onde este e diversos trabalhos sobre outros temas serão avaliados e discutidos pela turma.
Para facilitar a obtenção destas páginas, criei uma versão compacta que possibilita a navegação offline.
As transparências da apresentação também podem ser obtidas numa versão compacta.
Hoje os sistemas de software podem ser considerados ilhas de automação. Cada componente do software executa alguma limitada faixa de funções, mas os componentes não interoperam efetivamente. A integração que existe é insuficiente e não se relaciona de forma adequada com as tecnologias componentes. A escala desse problema varia do desktop do usuário (vários aplicativos usam as mesmas funções e cada um tem o seu próprio código para isso, gerando repetições desnecessárias) até os níveis interorganizacionais (um bom exemplo pode ser a duplicação de dados em um banco). Como consequência desta pobre integração, podemos citar:
A solução básica para esta serie de problemas é o uso da CORBA. CORBA é uma tecnologia padrão para uma infraestrutura que visa a integração de sistemas, que entre outras facilidades, podemos citar:
Este trabalho visa fornecer uma visão geral do padrão CORBA e como ele pode ser usado.
O rápido crescimento do processamento distribuído ajusta-se à realidade atual, onde a informação pode ser armazenada e processada em pontos distintos, geograficamente separados em grande heterogeneidade de meios. O desenvolvimento tecnológico possibilita a produção de máquinas menores e mais rápidas, e isso também colabora para essa distribuição. A redução dos custos e dos tempos de desenvolvimento coopera do mesmo modo.
Nesse contexto, o paradigma da orientação a objetos é a abordagem mais apropriada ao desenvolvimento da tecnologia para suportar a computação distribuída, oferecendo soluções para problemas originados pela heterogeneidade, gerenciamento de configuração, contabilidade, monitoramento, etc, os quais tornam-se críticos numa distribuição em larga escala. Essa abordagem esta sendo utilizada por sólidos organismos de padronização, como por exemplo, pela ISO, ITU-T, APM e OSF.
Visando uma padronização para as plataformas que vão solucionar os problemas do processamento distribuído, a ISO, juntamente com a ITU-T, vem desenvolvendo um Modelo de Referência para ODP ( Open Distributed Processing ).
Dentre as várias plataformas existentes, a CORBA ( Common ORB Architecture ) afigura-se como uma das mais adequadas. A especificação dessa plataforma, entretanto, permite um alto grau de liberdade na sua implementação.
Nas próximas páginas deste trabalho serão apresentados os conceitos básicos da CORBA, as necessidades decorrentes do suporte à interoperabilidade e uma idéia da transparência de realocação entre ORBs interoperantes.
A OMG ( Object Management Group ) consiste num dos vários consórcios existentes de companhias que buscam produção de especificações para ambientes que utilizam a orientação a objetos, voltados para sistemas distribuídos. É responsável pela definição da plataforma ORB, a qual tem por objetivo fornecer, basicamente, mecanismos pelos quais objetos fazem requisições e recebem as respectivas respostas de forma transparente em ambientes distribuídos e heterogêneos.
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:
Diferentes ORBs podem fazer diferentes implementações e junto com compiladores IDL, repositórios e vários adaptadores de objetos, realizar uma série de serviços para clientes e implementações de objetos que tenham diferentes propriedades e qualidades.
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.
Existe uma variedade de implementações de ORBs possíveis com a "Common ORB Architecture" (CORBA). Nesta seção será apresentada algumas destas diferentes opções. Note que uma ORB pode suportar múltiplas opções e protocolos de comunicação.
Se temos um mecanismo de comunicação adequado, a ORB pode ser implementada com rotinas residentes no cliente e implementações. O stub cliente usa o mecanismo IPC (local e transparente) ou acesso direto à localização do serviço para estabelecer comunicação com as implementações. Códigos ligados à implementação são responsáveis por colocar no ar o banco de dados usado pelo cliente.
Para centralizar o controle da ORB, todos os clientes e implementações podem comunicar com um ou mais servidores cujo trabalho é direcionar as requisições dos clientes para as implementações. A ORB pode ser um programa normal no sistema operacional disponível, e o IPC poder ser usado para fazer a comunicação com a ORB.
Para realçar a segurança, a robustez e a performance, a ORB pode estar provida dos serviços básicos de um sistema operacional. Referências de objeto podem ser feitas de forma a não serem falsificada, reduzindo assim o custo de autenticidade de cada requisição. Como o Sistema Operacional pode saber a localização e a estrutura de clientes e implementações, isto será possível à uma variedade de optimização de implementação.
Para objetos leves e que a implementação pode ser dividida, a implementação será feita em bibliotecas. Neste caso, o stub pode ser podem ser os métodos atuais. Isto assume que é possível para o programa cliente acessar os dados do objeto e que esta implementação garante que o cliente não modificará os dados.
O cliente de um objeto tem uma referência de objeto que se refere à este objeto. Uma referência de objeto é um sinal que pode ser invocado ou passado como parâmetro para uma invocação em objetos diferentes. Invocação à um objeto envolve a especificação do objeto a ser invocado, a operação a ser realizada e os parâmetros que devem ser fornecidos à operação ou os parâmetros devolvidos pela operação.
A ORB administra a transferência de controles e dados para a implementação de objetos e sua volta ao cliente. Quando em um evento, a ORB não pode completar a chamada, é gerado uma excessão como resposta. Geralmente, o cliente chama uma rotina em seu programa que faz a chamada e retorna quando a operação é completada.
O cliente acessa um stub específico para um objeto como se estivesse acessando uma rotina de biblioteca no seu programa (ver figura 6). O programa cliente vê então as rotinas sendo chamadas normalmente na sua linguagem de programação. Todas as implementações irão prover o uso de uma linguagem específica de dados para referenciar os objetos, geralmente um ponteiro. O cliente depois passa a referência de objeto para as rotinas de stub para estas iniciarem a invocação. Os stubs tem acesso as representações de referência de objetos e interagem com a ORB para realizar a invocação.
figura 6 - Estrutura de um Cliente
Existe uma série de códigos de biblioteca que realizam as invocações à objeto, por exemplo, quando o objeto não foi definido à tempo de compilação. Neste caso, o programa cliente prove informações adicionais para obter o tipo de objeto e o método a ser invocado, e realiza uma sequência de chamadas que irão especificar os parâmetros e iniciar a invocação.
Clientes geralmente obtém as referências de objeto através de outras invocações a outro objeto que se tem referência e que fornece como saída a referência de objeto desejada. Quando o cliente também é uma implementação é uma implementação, ele recebe referência de objeto como parâmetro de entrada para a invocação de objeto que ele implementa. Uma referência de objeto pode também ser convertida em strings que podem ser guardadas em arquivos, ou reservada, ou transmitida de várias maneiras e depois recolocada como referência de objeto pela ORB que produz a string.
A implementação de objeto prove o estado atual e o comportamento com o objeto. Pode ser feita de várias maneiras. Além da definição de métodos para suas próprias operações, uma implementação usualmente definirá procedimentos para ativar e desativar objetos, e usará outros objetos ou estruturas não-objeto para fazer o estado do objeto persistente para controle de acesso à objeto.
A implementação de objeto (ver figura 7) interage com a ORB de diversas maneiras para estabilizar suas identidades, para criar novos objetos e para obter serviços dependentes da ORB. Primeiro ela faz acesso ao adaptador de objeto, que prove uma interfacepara o servico ORB conveniente para um estilo particular de implementação de objeto.
figura 7 - Estrutura de um Implementação de Objeto
Devido a grande variedade de implementação de objeto, fica difícil definir uma como padrão.
Quando acontece uma invocação, a "ORB Core", o adaptador de objeto e o esqueleto arranjam a chamada para o método apropriado de implementação. O parâmetro para este método especifica o objeto a ser invocado, o que o método pode usar para localizar os dados para o objeto. Parâmetros adicionais são suportados de acordo com a definição do esqueleto. Quando o método é terminado, ele retorna parâmetro ou excessões ao cliente.
Quando um novo objeto é criado, a ORB tem que ser avisado para saber onde achar a implementação para este objeto. Usualmente, a implementação se auto-registra como implementação de objeto de uma interface particular, e especifica como inicializar a implementação se esta não estiver rodando.
A maioria das implementações possuem este comportamento, usando recursos adicionais à ORB ou adaptadores de objeto.
O adaptador de objeto (figura 8) é o primeiro modo para a implementação de objeto acessar serviços ORB tal como referência de objetos. O adaptador de objeto exporta a interface pública para a implementação de objeto, e a interface privada para o esqueleto. Isto é construído em uma interface ORB privada.
Adaptadores de objeto são responsáveis pelas seguintes funções:
Estas funções são feitas através da "ORB Core" e qualquer componente adicional necessário. Frequentemente o adaptador de objeto irá manter o seu estado para realizar estas tarifas. Isto pode ser possível para um adaptador de objeto particular que delegue uma ou mais responsabilidades sobre a ORB, à qual ele foi construído.
Como mostrado na figura 8, o adaptador de objeto é implicitamente envolvido na invocação dos métodos, embora a interface direta seja através dos esqueletos. Por exemplo, o adaptador de objeto pode ser envolvido na ativação da implementação ou na autenticação do pedido.
figura 8 - Estrutura de um Adaptador de Objeto
O adaptador de objeto define vários serviços da ORB que a implementação de objeto pode depender. Diferentes ORB irão fornecer diferentes níveis de serviços e diferentes ambientes de operação que terão algumas propriedades implícitas e necessitarão que outras sejam adicionadas pelo adaptador de objeto. Por exemplo, é comum para a implementação de objeto querer guardar certos valores em referência de objetos, para se ter uma fácil identificação do objeto invocado. Se o adaptador de objeto permite em uma implementação especificar certos valores quando um novo objeto é criado, ele pode ser capaz de guarda-las em uma referência de objeto para a ORB que permita isto. Se a "ORB Core" não permite esta funcionalidade, o adaptador de objeto gravará este valor no seu próprio repositório e o fornecerá a implementação quando da invocação. Com adaptador de objeto, é possível par uma implementação de objeto ter acesso a um serviço que pode ser ou não implementado na "ORB Core"- se a "ORB Core" permite isto, o adaptador simplesmente prove uma interface para ele; se não, o adaptador o implementa no topo da "ORB Core". Todo adaptador tem que prover a mesma interface e serviço para toda ORB que é implementada nele.
Não é necessário todos os adaptadores de objetos proverem a mesma interface e funcionalidade. Algumas implementação de objetos tem necessidade especiais, por exemplo, uma base de dados orientda a objeto pode querer registrar implicitamente vários objetos sem fazer chamadas individuais ao adaptador de objeto. Neste caso, será impraticável e desnecessário para o adaptador de objeto manter qualquer objeto por estado. Usando uma interface de adaptadore de objeto calibrado pela implementação de objeto, é possível tomara vantagem de detalhes particulares da "ORB Core" para prover o acesso mais eficiente à ORB.
Existem vários tipos de adaptadores de objeto. A maioria dos adaptadores de objetos são desenhados para atender uma variedade de implementação de objeto, assim, somente quando a implementação requisitar diferentes serviços ou interfaces os novos adaptadores de objetos serão considerados. Nesta seção serão descritos 3 tipos de adaptadores de objetos.
Esta especificação define adaptadores de objetos que podem ser usados pela maioria dos objetos ORB, com implementação convencional. Para estes adaptadores de objetos, implementações são geralmente programas separados. Ele permite à existência de um programa inicializado pelo método e um programa separado para cada objeto, ou um programa compartilhado por todos os tipos de objeto. Prove uma pequena quantidade de armazenamento para cada objeto o que pode ser usado como nome ou identificador para outro armazenamento, para acesso à lista de controle, ou outras propriedades de objeto. Se a implementação não esta ativa quando a invocação é feita, a BOA irá inicializar uma.
Este adaptador de objeto é usado por objetos que possuem implementações de biblioteca. Ele acessa arquivos, e não suporta ativação e autenticação, desde que os objetos estejam no programa cliente.
Este adaptador faz conexão com uma base de dados orientada à objeto para ter acesso aos objetos armazenados no banco. Desde que a OODB prove métodos e armazenamento persistente, objetos podem ser registrados implicitamente e não são necessários estados no adaptadores de objeto.
Como previsto pela OMG, existe atualmente uma grande variedade de produtos que obedecem à especificação CORBA, entretanto, devido à grande flexibilidade permitida, as implementações de cada ORB diferem, refletindo as soluções peculiares de cada fabricante, não só pela utilização de diferentes mecanismos para a obtenção das mesmas funcionalidades preconizadas, como também através do acréscimo de novas funções, consideradas importantes para o seu usuário final. Este fato corresponde às decisões técnicas relativas, por exemplo, ao tempo despendido por uma requisição, ao escopo abrangido por uma ORB ( uma única aplicação ou todo o ambiente envolvido por uma empresa com conexões internacionais, por exemplo ), aos níveis de segurança e ao uso de determinados protocolos. Essa diversidade é possível pelo fato da CORBA ter bem definidas as interfaces da ORB, não se preocupando com a forma com que serão fornecidas. A referência de objeto, por exemplo, que compõe um poderoso mecanismo nessa arquitetura, originou várias formas de implementação, tornando complexo a utilização de uma referência desenvolvida para uma ORB por outra. Outros fatores podem, também, motivar a divisão de um ambiente em ORBs diferentes, tais como: segurança, criação de ambientes para desenvolvimento e gerenciamento, tempo de vida dos objetos utilizados, sua proximidade ou não com os clientes, etc.
Dessa necessidade surge o conceito de interoperabilidade, que é definido como: "A habilidade de um cliente numa ORB A invocar uma operação, definida em IDL, num objeto numa ORB B, onde ORB A e ORB B são desenvolvidas independentemente".
A interoperabilidade está basicamente associada com uma mudança transparente de domínio. Considera-se domínio como um escopo em que certas características e/ou regras comuns são preservadas. Há uma tendência de que esses domínios sejam, basicamente, de cunho administrativo (nomes, grupos, gerenciamento de recursos, segurança,etc) e/ou tecnológico (protocolos, sintaxes, redes, etc), sendo que os mesmos não correspondem, necessariamente, aos limites de uma ORB instalada.
Domínios possibilitam o particionamento de um escopo em grupos de objetos que tenham características em comum. Um determinado objeto pode, portanto, fazer parte de mais de um domínio, desde que satisfaça a todos os seus requisitos. Considera-se o limite de um domínio como o 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.
O problema básico de se conseguir interoperabilidade pode ser traduzido em como fazer para que um objeto Y, na ORB B, apareça como um objeto X, na ORB A, de maneira que esta última seja capaz de utilizar X da mesma forma que faria com um objeto qualquer que fosse, de fato, implementado por ela. Além disso, todas as funcionalidades fornecidas pela ORB B devem ser acessíveis pela ORB A através de X. Com isso, uma requisição em X deve ser transformada numa requisição em Y e, para tanto, devemos ser capazes de criar X através da passagem de Y para a ORB A. O objeto X será, então, um representante de Y na ORB A, recebendo a denominação de proxy de Y.
Durante a conversão da requisição pode ser necessário o mapeamento de outros domínios, além do definido pela referência de objeto. Múltiplos domínios podem estar sendo ultrapassados simultaneamente e cada conversão será igualmente necessária para o completo entendimento pela ORB destino. Uma forma de se conseguir interação entre duas ORBs é através de um Interceptador. Esse mecanismo possibilita que uma invocação iniciada numa ORB seja atendida por um objeto em outra ORB. Logicamente um Interceptador é posicionado entre os dois domínios que tem por objetivo unir.
O mecanismo de interceptação pode ser:
Pela localização de seus componentes o Interceptador pode ser:
O interceptador utilizará operações definidas na CORBA.
Através da transparência de localização, objetos têm seus serviços solicitados sem que o cliente necessite possuir qualquer indicação de sua posição. A transparência de realocação estende esse conceito para objetos que se movimentaram entre invocações. A ORB garante a transparência de localização e acesso. A especificação CORBA contempla mecanismos que garantem a transparência de realocação. Ocorrendo movimetação de um objeto, torna-se necessário um mecanismo que possibilite que as novas requisições sejam enviadas ao objeto na sua nova localização, de forma transparente ao cliente.
Como mostra o texto, a ideia básica da operação da CORBA é simples, porém devido ao grande número de acrônimos, e terminologias que podem não ser muito comuns, a sua implementação e arquitetura se tornam um tanto quanto complicada. A convivência com os termos e a criação de algumas aplicações rapidamente resolvem esse problema.
A ideia do processamento distribuído não é nova, e pelo tempo que possui de vida, ao meu ver, ja deveria estar mais adiantada. Com o aumento da capacidade de processamento do computadores estando sempre em alta, acredito que poucos são, e serão, os problemas práticos que podem tirar algum proveito dessa arquitetura. Pelo mesmo motivo, a segurança nos sistemas distribuídos se torna frágil, quando não, esses sistemas são demasiadamente lentos.
Algumas opções de implementação proprietária para o processamento distribuido ja estão em uso ( pela Microsof , Sun, etc ). Uma comparação e algumas observações sobre eles podem ser vistas num pequeno FAQ sobre o assunto.
SIEGEL, JON, COORD.
CORBA FUNDAMENTALS AND PROGRAMMING.
NEW YORK : JOHN WILEY, C1996.
MOWBRAY, THOMAS J
ESSENTIAL CORBA : SYSTEMS INTEGRATION USING DISTRIBUTED OBJECTS.
NEW YORK : JOHN WILEY, C1995.
http://www.corba.org/
http://corbaweb.lifl.fr/
http://www.infosys.tuwien.ac.at/
Devido ao grande número de acrônimos relacionados a CORBA, parece propício a criação de um pequeno dicionário. Segue abaixo algumas descrições importantes, que foram mantidas no idioma original para não comprometer a compreensão dos termos.
Computação Distribuída permite usuários diferentes ou computadores compartilhar informação. Computação Distribuída pode permitir uma aplicação em uma máquina usar o poder de processamento, memória, ou armazenamento em outra máquina. É possível que computação distribuída possa aumentar o desempenho de uma aplicação isolada, mas esta não é freqüentemente a razão para distribuir uma aplicação. Algumas aplicações, como processador de textos, poderiam não se beneficiar em danda da distribuição . Em muitos casos, um problema particular poderia exigir distribuição. Se uma companhia deseja colecionar informação por localizações, distribuição é um ajuste natural. Distribuição pode permitir aumentar desempenho ou disponibilidade em outros casos. Se uma aplicação tem que correr em um PC e a aplicação precisa executar cálculos longos e distribuir estes cálculos para máquinas mais rápidas poderia permitir aumentar desempenho.
Um objeto distribuído é um objeto que pode ser acessado remotamente. Isto significa que um objeto distribuído pode ser usado como um objeto regular, mas de em qualquer lugar da rede. É considerado tipicamente que um objeto encapsula dados e comportamento. A localização do objeto distribuído não é crítica ao usuário do objeto. Um objeto distribuído poderia proporcionar para seu usuário um jogo de capacidades relacionadas. A aplicação que provê um jogo de capacidades está freqüentemente chamado um serviço. Um Objeto Empresarial poderia ser um objeto local ou um objeto distribuído. O termo que objeto empresarial se refere a um objeto que executa um jogo de tarefas associado com um processo empresarial particular.
No máximo nível básico, CORBA é um padrão para objetos distribuídos. CORBA permite a uma aplicação solicitar a execução de uma operação por um objeto distribuído e os resultados da operação serem retornados à aplicação que faz o pedido. A aplicação comunica com o objeto distribuído que está executando a operação de fato. Esta é funcionalidade de cliente/servidor básica onde um cliente emite para um pedido a um servidor e o servidor responde atrás ao cliente. Dados podem passar do cliente ao servidor e podem ser associado com uma operação particular em um objeto particular. Dados são retornados ao cliente na forma de uma resposta.
Um servidor é definido como uma Interface em CORBA IDL. Dados que passam entre o cliente e o servidor são definidos como estruturas IDL, sucessões, etc. O IDL é compilado com um compilador de IDL e o código gerado é incluído dentro dos processos do cliente e do servidor. O servidor implementa uma interface particular. O implementação é o objeto distribuído. Clientes se comunicam com o objeto por uma referência de objeto. Quando uma operação é executada na referência de objeto, comunicação de cadeia acontece, são enviados parâmetros de operação ao servidor e o objeto distribuído atual executa a operação. Após isso, devolve qualquer dados apropriado então ao cliente.
Depende do vendedor específico e produto oferecido, mas não há nada no padrão que você achará terrivelmente oneroso.
Algumas aplicações querem fazer pedidos distribuídos, mas não espera pela resposta. Idealmente, eles querem ser notificados quando a resposta está disponível. Podem ser usadas linhas para permitir para aplicações fazer mais de um pedido ou continuar executando outras tarefas enquanto esperando por uma resposta, mas a linha que faz um pedido é bloqueada até a resposta está disponível. Comunicação de CORBA é basicamente uma requisição/resposta síncrona. Isto é verdade para todas as chamadas estáticas. Chamadas dinâmicas apoiam uma resposta de pedido adiada. Isto significa que uma aplicação pode emitir um pedido e pode aguardar a resposta. Pode ser usada comunicação de CORBA para notificar aplicações quando respostas associaram com pedidos mais cedo está disponível. Isto pode conduzir a uma arquitetura de aplicação mais complexa.
Antes de você que você possa usar CORBA para comunicação de client/server que você tem que implementar seu próprio corretor de pedido que apóia porções da especificação de CORBA inclusive IIOP (não sugiro) ou você pode obter um corretor de pedido de objeto que implementa a especificação de CORBA. Muitas companhias vendem corretoras de pedido de objeto que implementam tudo ou alguma da especificação de CORBA, incluindo várias partes do CORBA 2. x e 3.x , serviços CORBA , e outras integrações de terceiros. São incluídos links para os sites abaixo:
Informações adicionais pode ser encontradas em: * OMG List of free stuff.
DCOM é uma solução específica da Microsoft para distribuição . Produtos CORBA estão disponíveis em mais de 20 vendedores diferentes. Produtos CORBA apoiam qualquer sistema operacional ( Microsoft ou não ). CORBA é um mecanismo excelente para atravessar o caminho entre as estações Microsoft e os servidores UNIX.
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e DCOM. Por exemplo, uma aplicação de cliente poderia ser desenvolvida para ter acesso um conjunto de objetos de automatização OLE , e esse objetos poderiam receber em troca objetos CORBA rodando em uma plataforma de não Microsoft tal como um UNIX. O OMG definiu uma especificação COM < - CORBA para interconexões que unifica este tipo de ligação.
CORBA existe desde 1990. Implementações comerciais estão disponíveis desde 1992. DCOM ficou disponível em forma de beta em 1996. CORBA teve mais tempo para amadurecer. Também há um número grande de companhias diferentes desenvolvendo ORBs CORBA . Este nível de competição aumenta a robustez da soluções de CORBA em geral.
DCOM é bem ajustado para desenvolver apliacações front-end. Se as aplicações rodam sobre a plataforma da Microsoft, DCOM poderia ser uma escolha boa. DCOM também pode ser usado com CORBA. A pergunta não é se eu deveria usar DCOM ou CORBA?
O OSF desenvolveu um Ambiente de Computação Distribuída (DCE) bem antes de CORBA ser desenvolvido. Já existe uma base instalada de baseada em sistemas distribuídos DCE . Porém, o número de vendedores de DCE, e o número de plataformas suportadas por DCE é pequeno comparado a CORBA.
Os ambientes CORBA e DCE podem interoperar com o tipo correto de gateway. DCE é reconhecido pelo OMG como um ambiente importante e padronizou o DCE-ESEIOP ( DCE Environment Specific Interoperability Protocol ).
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e DCE. Por exemplo, uma aplicação cliente poderia ser desenvolvida para ter acesso um jogo de objetos de DCE, e objetos de DCE poderiam ter acesso a objetos CORBA em troca. O OMG definiu um especificação de interconexão entre DCE < - >CORBA que unifica este tipo de relacionamento.
Não. DCE foi desenvolvido antes de CORBA. Isto dá para DCE um registro de rasto mais longo de instalações de sistema prósperas e fracassadas.
Uma distinção principal entre DCE e CORBA, porém, é que CORBA foi desenvolvido com o benefício de conceitos da orientação a objetos.
Outra distinção entre DCE e CORBA é a abrangência do padrão. CORBA é uma especificação mais ampla, e aponta para unificar definições de interface e serviços em ambiente comum de uma maneira orientada a objetos.
Enterprise Java Beans (EJB) é uma nova tecnologia para processamento distribuído. Sendo novo, EJB oferece simultaneamente atração (é novo! ) e risco (é novo! ). EJB não tem a larga base instalada da CORBA, nem tem tudo dos serviços. Mas, indubitavelmente, com o passar do tempo, desenvolvimentos de EJB e serviços crescerão. As distinções principais entre EJB e CORBA estão na flexibilidade e enfoque:
Os ambientes CORBA e de EJB podem naturalmente interoperar a nível de rede. Computação distribuída com Core Java e EJB usa Java Remote Method Invocation (RMI) para o protocolo de rede. CORBA’s IIOP e Java’s RMI são compatíveis no sentido de que IIOP pode transportar chamadas baseadas em RMI.
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e EJB. Por exemplo, uma aplicação de cliente poderia ser desenvolvida para ter acesso um grupo de EJB e objetos CORBA sem distinção. Há algumas diferenças nos padrões de desígnio de interface nos dois ambientes.
Sim. EJB foi desenvolvido recentemente, bem depois de CORBA ter passado pelos seus problemas de adoção. Isto dá para CORBA um vasto registro de instalações de sistema prósperas e fracassadas. Porém, isto dá para EJB o benefício de handsight. Nós dissemos que "EJB é CORBA combinada com algumas melhores práticas." Isto significa indicar
CORBA foi usado em uma variedade de indústrias em sistemas no mundo real . Reconheça que o domínio de problema que CORBA se dirige, i. e. , computação distribuída, é um domínio complexo. Qualquer sistema no mundo real de computação distribuída é complexo, possivelmente assuntos de endereço de tolerância de falta, disponibilidade, transações, mensagens, persistência, desempenho, e escalabilidade, isso só para mencionar alguns. CORBA provê infra-estrutura, serviços, e ferramentas para desenvolver soluções neste domínio complexo. A maioria dos sucessos e fracassos de CORBA não deveria ser associado como um todo à tecnologia, mas bastante o uso da tecnologia como parte de uma arquitetura.
Abaixo há uma lista de algumas histórias de sucesso da CORBA disponível na rede. Esta não é uma lista completa, mas bastante como um ponto de partida:
Sim.
Existe um numero de forma com que objetos CORBA podem ser acessados via aplicações baseada na web: