CORBA – Common Object Request Broker Architecture
Carolina de Oliveira Cunha
Lenita Martins Ambrosio
Victor da Fonseca Santos
Introdução
OMG (Object Management Group): uma organização formada por empresas de diferentes ramos da informática que trabalham sem fins lucrativos, para promover a criação e elaboração de modelos e padrões que proporcionem a interoperabilidade entre aplicações que usam tecnologia OO.
Criou a arquitetura CORBA
O que é CORBA?
CORBA (Common Object Request Arquitecture Broker)
Padrão proposto pela OMG
Estrutura comum para o desenvolvimento utilizando técnicas de OO em redes heterogêneas
Propõe a interoperabilidade local ou remota entre aplicações, independente das linguagens de programação em que foram desenvolvidas e sobre quais plataformas serão executadas
O que é CORBA?
Objetivo: promover a intercomunicação de objetos distribuídos em uma rede de computadores, a fim de executar alguma tarefa
Porém o CORBA é uma parte de uma outra tecnologia proposta pela OMG, chamado OMA (Object Management Architecture)
O que é CORBA?
Composto por 4 componentes principais:
ORB: define um barramento comum para troca de mensagens entre os objetos.
Objetos de serviço: ampliam a funcionalidade do ORB e gerenciam os objetos
Facilidades comuns: definem as interfaces no nível da aplicação.
Objetos da aplicação: objetos utilizados pela aplicação do usuário final.
Modelo de Objetos
Objetos distribuídos CORBA são pequenas partes de um sistema maior
Essas partes estão distribuídas na rede e podem ser acessados por métodos de invocação
Objetos clientes podem ser remotos ou não
Semântica dos Objetos
Principal característica: disponibilizar serviços a um determinado cliente, onde este é qualquer entidade capaz de requisitar tais serviços.
A seguir algumas semânticas que serão abordadas no corpo deste trabalho:
Semântica dos Objetos
Objetos: entidade de identidades encapsuladas, com a capacidade de prover serviços aos clientes.
Requisições: evento que pode ser utilizado por um cliente para solicitar um serviço de um determinado objeto. Nesta operação, deve conter informações do tipo da operação executada, o objeto alvo, zero ou mais parâmetros e alguns textos adicionais para a requisição.
Formulário de requisição: descrição ou padrão que podem ser avaliados ou executados em vários tempos para provocar uma emissão de pedido;
Valores: algo que pode ser legalmente utilizada como parâmetro em uma requisição;
Referência a objetos: determinado valor que se relaciona especificamente a um determinado objeto.
Semântica dos Objetos
Criação e destruição de objetos: objetos podem ser criados ou destruídos de acordo com as necessidades do pedido de um emissor.
Tipos: identificação de uma entidade que possui características associadas ao seu valor. Os "tipos" são usados para restringirem a possibilidade de determinados parâmetros ou caracteres sejam apresentados como resultados.
Tipos Básicos: 16 bits, 32 bits e 64 bits; precisão simples (32 bits), precisão dupla (64 bits); caracter; booleano; string; constantes.
Tipos de Construções Possíveis: Tipo seqüência; tipo matriz; tipo interface; tipo record.
Interfaces: um conjunto de operações que podem ser requeridas por um cliente satisfazendo suas necessidades.
Semântica dos Objetos
Operações Entidade identificadora que denota os serviços que podem
ser requeridos e identificados por um identificador de operações.
As informações necessárias para sua ativação (envio de parâmetros, retorno de resultados, tratamento de exceções, semântica e informação de contextos) são relacionadas em sua assinatura.
Na especificação CORBA, as "operações" são tratadas de forma genérica.Em outras palavras, a mesma operação para vários objetos de diferentes características. Isso é possível, pois há uma total desvinculação dos detalhes da implementação de uma interface e também porque há utilização de herança.
Parâmetros: valores necessários para a execução de uma determinada operação, dados no momento da requisição de um determinado serviço. Os parâmetros se caracterizam por:
Modo: sentido que flui a informação representada pelo parâmetro, referenciando-se sempre com o servidor, podendo ser in, out, in-out.
Tipo: está relacionado aos possíveis valores que podem ser transmitidos por meio desse parâmetro.
Valor de Retorno: parâmetro out especial que tem como finalidade simplesmente transmitir, quando necessário, o resultado de uma operação.
Exceções: indicam que uma requisição a uma operação não foi executada corretamente. Em outras palavras, ocorreu um erro durante a prestação de um determinado serviço. Os tipos de erros que podem ocorrer ou estão ligados ao sistema propriamente dito ou a própria implementação do objeto que provê tal serviço desejado.
Contextos: informações adicionais e especiais, diferenciando-se dos valores dos parâmetros tradicionais. Entretanto, apesar de serem valores especiais, estes podem afetar no resultado de uma operação.
Semântica dos Objetos
Semântica dos Objetos
Semânticas de execuções: existem duas formas de se executar uma operação:
No máximo uma: se uma determinada operação foi executada com sucesso, é por que a mesma fora executada uma única vez, com sucesso. Outra possibilidade: havendo a emissão de uma exceção, significa dizer que a operação fora executada apenas uma vez e fora possível, nesta única execução da operação, alcançar o resultado desejado.
Melhor Esforço: não é esperado, pelo cliente, nenhum tipo de resultado da operação, por isso o cliente não precisa ficar ocioso por uma resposta. Para que um cliente nunca fique esperando por um resultado de uma operação que nunca virá, as informações necessárias sobre a semântica da execução estão anexadas pela assinatura, garantindo assim que os clientes e servidores fiquem cientes da natureza da operação (no máximo uma – melhor esforço)
Semântica dos Objetos
Atributos: declarações feitas para permitir a manipulação de valores do objeto
servidor.
Um atributo equivale logicamente a declaração de funções de acesso (uma para receber o valor do atributo e outra para escolher o valor do atributo). Entretanto um atributo pode ser definido como só de leitura.
Herança: conceito herdado do Paradigma de Orientação a Objeto, adotado e
utilizado pela especificação CORBA.
O CORBA permite utilizar herança para criar tanto novas interfaces como novos objetos. Ele implementa múltipla herança, porém não é possível herdar de duas classes que tenham mesmo nome de operação ou de atributo.
Não é possível alterar os nomes das operações ou atributos herdados nas classes derivadas, podendo apenas serem redefinidos nomes de tipos, constantes ou exceções.
O CORBA ainda permite múltipla herança com metaclasses (metaclasse é uma classe de objetos criada em tempo de execução).
Componentes da Arquitetura CORBA
Clientes
Toda entidade responsável por invocar uma determinada operação sobre uma implementação de objeto.
Os detalhes utilizados para que seja feito esse acesso aos serviços de um determinado objeto é transparente e dispensável do conhecimento do cliente, precisando o mesmo apenas saber interagir com a interface do tal objeto.
Essa invocação feita pelo cliente poderá ser feita utilizando-se o stub ou utilizando-se um conjunto de rotinas de invocações feitas dinamicamente através da interface DII
Implementação de Objetos
Operações que podem ser implementadas em uma interface ORB IDL.
Tem informações de objetos, como dados internos, os códigos de seus métodos e seus respectivos procedimentos de ativação e desativação determinados na criação do objeto.
Componentes da Arquitetura CORBA
ORB
Interface ORB
Stub
Skeleton
Interface de Invocação Dinâmica (DII)
Interface de Esqueleto Dinâmico (DSI)
Adaptador de Objeto
Componentes da Arquitetura CORBA
ORB - Object Request Broker
Middleware da especificação CORBA
Uma das partes mais importantes do CORBA
Componente que define o barramento comum, criado para facilitar a comunicação entre objetos
Permite que objetos façam, de forma transparente, requisições a objetos que podem estar localizados localmente ou remotamente
O usuário não precisa se preocupar onde tal objeto está localizado, em que sistema operacional ele roda ou qual programa foi usado para desenvolvê-lo.
ORB - Requisições
É um pedido feito pelo cliente ao ORB
Componentes de uma requisição:
Referência ao Objeto: identifica o objeto desejado
Operação: identifica qual a operação deve ser executada
Parâmetros: dados necessários para a execução da operação;
ORB - Requisições
Quando um cliente invoca uma operação, a ORB fica responsável por encontrar a implementação do objeto, sua ativação e se necessário, entregar a requisição ao objeto e retornar qualquer resposta a quem o invocou. O cliente faz uma requisição Com isso, invoca ou cria uma rotina do Stub. A
implementação do objeto não precisa saber o tipo de método de invocação foi utilizado
O pedido é repassado para o ORB que fica responsável em encontrar a implementação do objeto, para então transmitir os parâmetros e o controle para essa implementação, tudo isso utilizando um Skeleton IDL específico da interface e através do adaptador de objetos
Então, a implementação do objeto acessa o ORB através de um adaptador de objetos, retornando para o cliente o resultado da operação
ORB - Referência a objetos
Para um cliente realizar uma requisição a um objeto, precisa ter uma referência ao mesmo, é importante dizer que cada objeto possui uma identificação única.
Existem várias maneiras de se obter uma referência a objeto: Criação de Objetos: o CORBA cria objetos. Os objetos são
criados por meio de invocações sobre objetos-fabricas, localizados no servidor de objetos. Essa operação gera uma referência ao objeto criado.
Serviço de Diretório: é permitido ao cliente invocar um determinado tipo de serviço de procura, para que possa achar referências a objetos.
Conversão de Referência em String e Vice-Versa: permite a conversão de uma referência a objeto em uma string, podendo a mesma futuramente ser recuperada e ser transformada novamente em referência a objeto.
ORB
Os serviços restantes que fazem do ORB um middleware, estão relacionados aos serviços a nível de sistemas, que oferecem outros tipos de serviços como: segurança, persistência entre outros.
O ORB ainda apresenta algumas deficiências: falta de mecanismos de controle de concorrência, de
balanceamento de carga e de coleta de lixo Não se dispõe de servidores de tolerância a falhas, o
que é feito para uma maior confiabilidade é a replicação de objetos.
não trabalham com produtos "chaves" das empresas de hoje, que são justamente monitores de processamento de transações, sistemas de banco de dados orientados a objetos e nem relacionais, dificultando assim a integração do ORB ao ambiente cliente/servidor já existente nas empresas.
Invocações
Processo de se chamar um método para que seja feito um acesso a um serviço de um objeto
Três formas de invocações existentes no CORBA:
Invocação Síncrona: o cliente fica travado esperando o resultado
Invocação Síncrona Deferida: o cliente pode executar outras chamadas e posteriormente receber os seus resultados.
Invocação ONEWAY: é usada pelo cliente quando não necessita de resultado, ficando livre para continuar seu processamento.
Dois diferentes tipos de processos de invocações: Estática e Dinâmica
Invocação Estática
Gerada diretamente em um formulário do stub, e compilada pelo compilador IDL
O cliente está ciente de quais objetos e métodos estão disponíveis além de ter todas as interfaces do sistema já definidas.
É bom para programas que na hora de compilar a invocação, sabem quais as operações que vão precisar usar.
Stubs
Estão localizados no lado do cliente
Promovem interfaces estáticas para criar e enviar requisições aos serviços desejados
São gerados a partir da compilação da interface do cliente.
Quando um cliente deseja chamar um método de um objeto, basta apenas indicar qual o objeto que deseja
O stub que receber essa chamada, localiza o objeto desejado, transforma a chamada para que possa ser enviada pela rede e a transmite para o ORB
A comunicação entre o stub e o ORB se dá por meio de interfaces privadas.
Skeletons
Executam função similar ao Stub do cliente, no "lado" do servidor.
Tem como função encontrar os serviços que são solicitados pelo Stub.
O Skeleton receberá na sua criação o "pacote" do ORB, e irá descompactá-lo e envia-lo para a implementação do objeto
A requisição será recebida pelo objeto que irá executá-la, havendo alguma resposta, esta será enviada de volta ao cliente
O fato de existir um Skeleton, não implica em dizer que existe um Stub do outro lado, pois a invocação a ele pode ser feita de forma dinâmica
Passos para Invocação Estática
Definição da classe de objetos usando IDL;
Execução do arquivo IDL através de um compilador
Adicionamento do código de implementação para o skeleton
Compilação do código
Ativação das definições da classe através do Repositório de Interfaces
Instanciação do objeto no servidor
Registro em tempo de execução do objeto no Repositório de Interfaces.
Invocação Dinâmica
Caracterizam-se por permitir que programa/clientes possam dinamicamente construir e invocar requisições a objetos.
Todas as informações necessárias para que o cliente possa realizar o processo de invocação, são encontradas no Repositório de Interfaces.
Surgiram da necessidade de se eliminar o problema que ocorria quando se necessitava inserir um novo objeto. Era preciso parar todo o sistema para que ele pudesse ser recompilado
Com as invocações dinâmicas é possível adicionar um novo objeto em tempo de execução sem a necessidade de parar o sistema para tal.
Interface de Invocação Dinâmica
DII – permite descobrir ou construir dinamicamente uma invocação a um objeto, permitindo a inclusão do mesmo sem que seja necessário um conhecimento prévio de quais objetos ou métodos estão disponibilizados.
O cliente não precisa utilizar o Stub, os parâmetros são todos checados em tempo de execução e não de compilação.
Para se executar esse tipo de invocação, é necessário:
Identificar o Objeto Alvo;
Pegar a interface do Objeto ;
Construir uma invocação ou chamada;
Invocar a requisição e receber o resultado (quando houver).
Interface de Invocação Dinâmica
Permite que o cliente realize operações de envio e recebimento de forma separada e também operações unidirecionais.
Um ponto de desvantagem da invocação dinâmica, é que acarreta um maior tráfego na rede, já que necessita realizar acessos adicionais ao Repositório de Interfaces, além do fato de que verificar os parâmetros em tempo de execução prejudica também um pouco o sistema.
Interface Skeleton Dinâmica
DSI - trabalha de forma similar ao DII, para os objetos servidores
Permite que novos objetos servidores sejam criados sem a necessidade de se usar os Skeletons
Funcionamento de uma DSI: o ORB passa a chamada ao DSI Essas chamadas possuem informações sobre o objeto
chamado e a operação solicitada Essas informações são acessadas no Repositório de
Interface e nos Adaptadores de Objetos.
Apesar de ser dinâmica, é capaz de receber invocações tanto estáticas como dinâmicas
Uma vantagem é que a DSI é muito útil para a implementação de pontes genéricas (um mesmo padrão) na ligação entre ORB’s.
IDL e Interfaces
Interface é um conjunto de informações dos objetos que são disponibilizadas aos demais
Utilizando para isso uma mesma linguagem (IDL)
Com a finalidade de permitir a interação de um conjunto de objetos de naturezas diferentes
Sem que seja necessário se preocupar com detalhes individuais da implementação de cada objeto.
IDL e Interfaces
Devem utilizar uma linguagem que seja puramente declarativa, gerando apenas declarações e não códigos
IDL - é a linguagem adotada pela OMA para especificar toda a sintaxe de todas as interfaces
Repositório de Interfaces
É utilizado pela IDL para armazenar todas as definições dos objetos
Deve estar sempre disponível tanto ao cliente como ao ORB e às implementações
permite a descoberta das informações de tipo em tempo de execução
É um excelente suporte para as invocações dinâmicas
Adaptador de Objetos
Faz o papel intermediário na comunicação entre os objetos e o ORB, ajudando na entrega de requisições às implementações dos objetos e na ativação desses objetos
Necessário devido a grande diversidade de implementação de objetos.
Serviços Oferecidos: Registros de Implementações de Objetos : utilizado na
localização da implementação do objeto Geração de Referência a Objetos Capacidade de Invocações(em auxílio com o Skeleton) Ativar ou Desativar uma Implementação de Objeto Segurança das Interações: junto com o ORB deve
garantir a entrega das requisições por meio de conexões múltiplas sem bloquear nenhuma dessas conexões.
Adaptador de Objetos
BOA (Basic Object Adapter): Adaptador de objetos genéricos, incluso na especificação CORBA.
Podem ser desenvolvidos adaptadores especializados para determinada especificação.
Os adaptadores especializados seriam apenas complementares ao BOA, realizando pequenas tarefas. Porém, acabaram por ser utilizados também para suprir as deficiências do BOA.
Funcionamento do Adaptador de Objetos
O ORB recebe uma requisição para um objeto e verifica se o servidor esta ativo ou não;
Ativa o servidor, caso não esteja, e passa para o mesmo todas a informações necessárias para a comunicação com o BOA;
O servidor envia uma mensagem para o BOA comunicando que está tudo pronto para interagir com ele;
O BOA passa a referência ao objeto para a rotina de ativação do objeto desejado, para que seja possível a sua ativação pelo servidor;
O BOA passa a invocação para o objeto, utilizando-se do Skeleton, e no momento que receber a resposta, a repassa para o cliente;
Funcionamento do Adaptador de Objetos
Se o BOA receber algumas chamadas adicionais sobre esse determinado objeto, ele (BOA) passará novas invocações ao objeto, entretanto o BOA pode receber novas chamadas, mas agora para um outro objeto, nesse caso ele precisará passar a referência ao objeto para a rotina de ativação do objeto, o servidor ativa esse objeto e depois é feita a invocação a esse outro objeto;
O servidor pode precisar desativar um objeto, para isso ele envia uma mensagem ao BOA comunicando que o objeto "x" será desativado;
O servidor pode também precisar se desativar, nesse caso, também enviará uma mensagem ao BOA comunicando-o do fato.
Adaptador de Objetos
De acordo coma especificação OMG, podem ser empregadas 4 políticas para a ativação de uma implementação de objeto pelo adaptador de objetos: Política Compartilhada de Servidor: permite que
objetos múltiplos possam ser executados no mesmo programa;
Política Não-compartilhada de servidor: objetos múltiplos não podem ser executados no mesmo programa;
Política de Servidor por Método: política onde um servidor é ligada toda vez que é recebida uma requisição;
Política de Servidor Persistente: o servidor fica sempre ativo.
Interoperabilidade
Com o avanço da tecnologia CORBA, foram surgindo no mercado ORB’s de diferentes fabricantes. Com isso, surgiu a necessidade de tratar a interoperabilidade entre esses ORB’s.
A questão não era apenas diferentes implementações dos ORB’s, mas também envolvia a segurança na comunicação e a disponibilização de um ambiente confiável de "teste" para os produtos que ainda estavam sendo desenvolvidos.
Interoperabilidade
CORBA 2.0: criação de domínios.
Um determinado objeto pode fazer parte de mais de um domínio, desde que satisfaça a todos os seus requisitos.
Limite de um domínio: 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.
Pontes
Fazem a conexão entres os objetos de diferentes domínios.
Devem ser capazes tanto de fazer a comunicação de domínios que se baseiam em uma mesma implementação quanto domínios que se baseiam em implementações diferentes.
Podem trabalhar de duas maneiras: Imediata(Direta) ou Mediada (Indireta).
Pontes Imediatas(Diretas)
Boa velocidade de comunicação
Menos geral, pois as requisições são transformadas diretamente da forma interna de um ORB para a forma interna do outro, daí o nome Diretas.
Pontes Mediadas(Indiretas)
Há um tradutor na extremidade de cada domínio
A requisição, através do tradutor do ORB, é traduzida da forma interna do ORB que a está transmitindo para um padrão comum entendido por todos os tradutores da rede.
Após a tradução, a requisição é enviada até o tradutor do ORB destinatário, onde o mesmo irá traduzir desse padrão comum para a forma interna de seu ORB.
Mais lenta que a Ponte Imediata.
Pontes
Além dessas duas classificações para a forma de comunicação entre os domínios, ainda podem ser aplicadas mais duas:
Ligações em Linha: quando são implementadas do interior do ORB. Pode ser feita por meio de um requerimento ao ORB para o fornecimento de serviços adicionais, ou por meio de introdução de códigos adicionais no stub e skeleton.
Ligações de Nível de Requisição: quando são implementadas em camadas superiores ao ORB.
GIOP
Para que as pontes se tornassem operáveis, foi especificado GIOP (General Inter-ORB Protocol), um padrão que atende às premissas (especificando formato das mensagens e uma representação comum para os dados) e permite a interligação ORB-para-ORB, além de ser capaz de trabalhar sobre qualquer protocolo de transporte.
Foi adotado o TCP/IP como protocolo de transporte padrão. Com isso surgiu o IIOP (Internet Inter-ORB Protocol).
IIOP
Especifica como as mensagens de padrão GIOP são transmitidas por meio de uma rede TCP/IP.
O IIOP possibilita o uso da própria internet como backbone entre os ORB’s.
O IIOP provê interoperabilidade também entre ORB’s compatíveis ao padrão CORBA.
A especificação de interoperabilidade da OMG definiu também o ESIOP (Environment-Specific Inter-ORB Protocol), como um conjunto de protocolos que permitem a interoperabilidade entre implementações baseados em GIOP, mas que utilizam protocolos proprietários de transportes.
Segurança
São implementados alguns serviços para garantir a segurança da transmissão das requisições, a saber:
Segurança - Autenticação
Identificador único, que permite ao cliente acessar qualquer servidor em qualquer lugar.
A autorização se procede a partir de um simples logon, que pega a autenticação e lhe oferece um conjunto de opções de segurança para a comunicação.
Para uma maior segurança, nenhum password é armazenado no login script do cliente.
Após feita a autenticação de um cliente em um determinado ORB da rede, o mesmo (ORB) se encarrega de propagar a autenticação por todo o resto da rede.
Segurança - Autorização
Após feita a autenticação do cliente, os servidores de objetos ficam encarregados de verificar quais operações podem ser feitas por aquele determinado cliente.
Para tal, os servidores usam as ACLs que contém uma lista de nomes e suas respectivas operações que podem ser executadas pelos mesmos.
É possível implementar várias políticas de ALC, podendo ser implementadas tanto pelo ORB como pelos servidores de objetos.
Segurança – Audit, Criptograia, Non-Reputdiation
Audit Serviço que monitora todos os eventos que
ocorrem no ORB, incluindo logons de clientes, quais objetos estão sendo usados e com quais servidores.
Considerado como parte fundamental na segurança, pois tem a capacidade de detectar possíveis intrusos.
Criptografia
Non-Reputdiation "guardas eletrônicos" que protegem todas as
partes no sistemas de possíveis falsos pedidos de requisições.
Vantagens na utilização de CORBA
Vantagens na utilização de CORBA, e outras arquiteturas de objetos distribuídos Os programadores não precisam mais se
preocupar com os detalhes de programação de baixo nível de rede, já que o nível de aplicação desse protocolo é apresentado como métodos de objetos definidos pela IDL, que apresenta-se mapeado para todos os propósitos;
Como o próprio nome já nos mostra, essa arquitetura absorve todos os conceitos de orientação a objetos existentes;
Com a utilização de applets, é possível acessar diretamente o conteúdo desejado, não necessitando assim de um browser intermediário na comunicação;
Vantagens na utilização de CORBA
A utilização de múltiplos threads permite a elaboração de ricas apresentações e possibilita aos servidores web atenderem vários clientes ao mesmo tempo;
O cliente pode criar um objeto e pedir que o mesmo referencie o servidor, sem precisar verificar no mesmo se algum evento ocorreu. Assim, o servidor apenas chamará o cliente quando o evento ocorrer.
A arquitetura CORBA utiliza o JAVA para acessar
os clientes web.
Implementações CORBA
ORBIX
http://web.progress.com/en/orbix/
VisiBroker
http://www.microfocus.com/products/visibroker/
Referências
http://www.gta.ufrj.br/grad/00_2/corba/
http://www.corba.org/
http://www.omg.org
Top Related