CORBA - Projetos

Sumário
Introdução ..................................................................................................................................... 03
1 - Integração com Java / Internet ................................................................................................ 04
1.1 - Mapeamento Java-to-IDL ......................................................................................... 04
1.2 - Firewall ..................................................................................................................... 05
1.3 - Interoperable Naming Service .................................................................................. 05
2 - Qualidade de Controle de Serviço .......................................................................................... 06
2.1 - Asynchronous Messaging ........................................................................................ 07
2.2 - Minimum, Fault-Tolerant and Real-Time CORBA .................................................. 07
3 - Pacote de Componentes Corba ............................................................................................... 08
3.1 - Objetos CORBA Passáveis por Valor ...................................................................... 08
3.2 - Componentes de CORBA e CORBA Scripting ....................................................... 08
Conclusão ..................................................................................................................................... 11
Bibliografia................................................................................................................................... 12
3
Introdução
O grande crescimento da informática dentro das empresas levou, ao longo dos últimos
anos, à necessidade de se conectar sistemas e fazê-los trabalharem juntos. Para que isso fosse
possível, foi preciso estabelecer um padrão para que esses sistemas “conversassem” entre si, e
tirassem proveito do trabalho em conjunto.
O empenho em busca desse padrão deu origem ao CORBA (Common Object Request
Broker Architecture), que é resultado da união de várias empresas como Sun, Oracle, IBM, entre
outras grandes companhias, em prol de uma padronização na programação de sistemas
distribuídos. Juntas, essas empresas formam o OMG (Object Management Group), grupo
responsável entre outras funções, por manter as especificações que definem um modelo padrão de
interoperabilidade entre aplicações, que funcionam em diferentes plataformas, protocolos e
implementações.
O modelo se baseia basicamente em três importantes conceitos: orientação a objetos,
integração e reuso de componentes e um ambiente de computação aberto e distribuído. CORBA
se baseia no modelo de cliente / servidor, onde um programa faz um pedido a outro em uma rede.
O padrão adiciona um mediador entre os dois agentes, a fim de reduzir a complexidade de
implementação da interação entre o cliente e o servidor. Esse mediador, denominado ORB
(Object Request Broker), é a estrutura mais importante da arquitetura CORBA. É ele quem faz o
intermédio das informações, e faz com que a transação seja transparente para cada um dos
agentes durante seu processo. O ORB é o responsável por localizar os objetos para qual se
destinam as requisições dentro da rede, bem como o envio dos parâmetros da requisição no
formato aceito por estes objetos. Se houver retorno de parâmetros de saída para o cliente, o ORB
se responsabiliza por entregar para o cliente essa informação também.
A implementação de uma aplicação CORBA é semelhante a qualquer outra aplicação
orientada a objetos, exceto pelo fato de incluir uma camada a mais para gerenciar a comunicação
de rede, quando um objeto reside em um processo que roda em outra máquina. Esta camada
adicional é formada por estruturas especiais denominadas stubs (agem do lado do cliente,
mascarando os detalhes envolvidos na comunicação com os servidores) e os skeletons (atuam do
lado do servidor, recuperando informações de solicitações a métodos e os executando, através do
4
adaptador de objetos). O adaptador de objetos é uma interface primária que uma implementação
usa para acessar funções do ORB.
A interface que o cliente utiliza, é totalmente independente e transparente a qualquer fator
relacionado a pouca homogeneidade do ambiente de rede no qual se encontra. Por exemplo, a
localização dos vários objetos disponíveis ou as várias linguagens de programação utilizadas para
o desenvolvimento desses objetos, não interferem na comunicação entre cliente e servidor.
Assim, qualquer software que forneça interfaces e os serviços especificados pode ser considerado
um ORB. A IDL, Linguagem de Definição de Interface do CORBA, descreve as interfaces das
implementações de objetos, que são acessadas por seus clientes.
CORBA, como qualquer tecnologia ou padrão, teve que evoluir continuamente desde sua
publicação para permanecer viável como uma base para aplicações distribuídas. Por exemplo, a
versão inicial de CORBA, publicada em 1991, não especificava um protocolo padrão para que as
aplicações pudessem se comunicar. Para poucos usuários CORBA, o fato de que cada ORB
usasse seu próprio protocolo de comunicação proprietário não era um problema. Isto porque a
maioria das aplicações de CORBA 1.0 eram pequenas o bastante para que cada uma confiasse
nos serviços de um único ORB. Porém, como as aplicações foram ficando maiores e mais
distribuídas, elas precisaram interagir com outras aplicações, eventualmente feitas usando um
ORB diferente. Como resultado, o General Inter-ORB Protocol (GIOP), e sua especificação para
implementação em cima de TCP/IP, o Internet Inter-ORB Protocol (IIOP), foi acrescentado à
versão 2.0 da especificação de CORBA, que foi publicada em 1995. Tais melhorias e
modificações de CORBA durante os anos, têm aumentado sua utilidade e aplicabilidade a uma
variedade sempre crescente de problemas de computação distribuídos. Este trabalho explica
várias características novas que estão sendo acrescentadas a CORBA, como parte de sua
evolução para versão 3.0.
5
A última vez que o número principal da versão de CORBA foi incrementado - para
CORBA 2.0 - significou a padronização de interoperabilidade. O que é novo e diferente o
bastante nesta versão, para a OMG incrementar o número de versão principal?
As especificações incluídas na designação de CORBA 3 se dividem nitidamente em três
categorias principais: Java e Integração de Internet; Qualidade de Controle de Serviço; e a
arquitetura de CORBAcomponent
1 - Integração com Java / Internet
As três especificações discutidas abaixo aumentam integração de CORBA com Java e a
Internet.
1.1 Mapeamento Java-to-IDL
CORBA 3 adiciona um mapeamento Java-to-IDL ao mapeamento IDL-to-Java “normal”,
bastante comum para quem já desenvolveu alguma aplicação Java/CORBA. Para usar este
mapeamento, começa-se escrevendo objetos RMI no que a especificação referencia como o
"subconjunto de RMI/IDL de Java". Este é um subconjunto bem completo; restrições afetam
itens como herança de multipath de métodos sobrepostos, caso de colisões de nome, e tipos
privados em interfaces. Objetos têm que estender java.rmi.Remote, e exceções têm que herdar
java.lang.Exception. Obviamente, objetos de CORBA passáveis através de valor, fazem um papel
importante na implementação do lado CORBA desta especificação.
Uma vez que você construiu os objetos, duas coisas acontecem: primeiro, compilando por
rmic com as próprias opções padrão, são gerados seus objetos CORBA, que usam IIOP ao invés
vez de protocolo de RMI. Segundo, o compilador de RMI vai produzir o IDL para seu objeto em
um arquivo que você pode compilar em qualquer linguagem de programação, em qualquer ORB,
o permitindo escrever para os clientes de CORBA em qualquer idioma, em qualquer linguagem
IIOP ORB que pode invocar seu objeto de Java.
Isto faz várias coisas. Transforma programadores de objetos Java em programadores
CORBA, e deixa objetos Java rodarem no ambiente de multilinguagem de CORBA. De acordo
com o primeiro desenho de EJB 1.1, é uma exigência futura para a interoperabilidade do
Enterprise JavaBeans e assegurará que estes EJBs possam funcionar bem neste ambiente de
multilinguagem.
6
1.2 - Firewall
A especificação de CORBA 3 define firewalls de nível de transporte, de nível de aplicação
e, talvez mais interessante, uma conexão bidirecional GIOP, útil para callbacks e notificações de
evento.
Firewalls de nível de transporte trabalham no nível de TCP. Definindo a porta 683 para
IIOP e 684 para IIOP sobre SSL, a especificação permite para os administradores configurar
firewalls para cooperar com CORBA, para que ele trafegue em cima do protocolo de IIOP.
Também há uma especificação para CORBA em cima de socks.
Em CORBA, objetos precisam freqüentemente fazer callbacks ou notificar o cliente que
os invocou. Para fazer isso os objetos agem como os clientes, e o módulo do lado cliente
instancia um objeto que é ligado de volta em uma invocação de direção contrária. Conexões
padrão de CORBA levam invocação somente de um modo, um callback requer tipicamente uma
segunda conexão de TCP para este tráfico, que é encabeçada na outra direção. Na especificação
nova, uma conexão de IIOP permite levar invocações na direção contrária, sob certas condições
restritivas, que não chegam a comprometer a segurança da conexão.
1.3 - Interoperable Naming Service
A referência do objeto CORBA é a base da arquitetura, isso porque o computer-readable
IOR era o único modo para alcançar uma instância e invoca-la, não havia nenhum outro modo
para alcançar uma instancia remota - até mesmo se você soubesse seu local - a menos que você
pudesse adquirir acesso a sua referência de objeto. O modo mais fácil para fazer isso era adquirir
uma referência a seu servidor de nomes, mas e se você não tivesse uma referência para isso?
O Interoperable Naming Service define uma referência de objeto no formato URL,
iioploc, que pode ser digitado em um programa para alcançar serviços definidos em um local
remoto, inclusive o servidor de nomes. Um segundo formato de URL, iiopname, realmente
invoca o serviço de nomes remoto, usando o nome que o usuário junta ao URL, e recupera o IOR
do objeto nomeado.
Por exemplo, um identificador de iioploc, iioploc://www.nome.com/NameService,
resolveria ao servidor de nomes CORBA a máquina cujo endereço IP correspondeu ao nome de
domínio www.nome.com.
7
2 - Qualidade de Controle de Serviço
2.1 – Asynchronous Messaging e Qualidade de Controle de Serviço
A nova especificação de mensagem define vários modos de invocação assíncrona e timeindependent para CORBA, e permite invocações estáticas e dinâmicas para usar qualquer modo.
Resultados de invocações assíncronas podem ser recuperados por callback ou polling - a escolha
é feita pela forma usada pelo cliente na invocação original.
Políticas permitem o controle de qualidade de serviço de invocações. Os clientes e objetos
podem controlar a ordenação (por tempo, prioridade ou prazo final), fixando prioridade, prazos
finais e tempo de vida, podem fixar começo e final para invocações dependentes de tempo e
controlar política de distribuição de rede.
A especificação também define roteadores CORBA e agentes store-and-forward para
invocações de IIOP. Roteadores com a qualidade máxima de serviço definido passarão
invocações com uma transação amigável, e armazenarão invocações de persistência, provendo
mensagens de transmissão de rede. A especificação de roteadores define interfaces de IDL ao
motor da máquina.
2.2 - Minimum, Fault-Tolerant and Real-Time CORBA
Minimum CORBA é principalmente planejado para sistemas embutidos. Sistemas
embutidos, uma vez que são finalizados e gravados para produção são fixos, e as interações deles
com a rede externa são previsíveis - eles não têm nenhuma necessidade pelos aspectos dinâmicos
de CORBA, como o DII ou o IR que suportam isto, por que estas características não são incluídas
em CORBA Minimum.
CORBA Real-Time unifica recursos de controle - linhas, protocolos, conexões e assim por
diante - usando modelos de prioridade para alcançar comportamento previsível por ambientes
real time rígidos e estatísticos. Planejamento dinâmico, que não é uma parte da especificação
atual, está sendo somada por um RFP separado.
8
3 - Pacote de Componentes Corba
3.1 – Objetos CORBA Passáveis por Valor
Objetos passáveis por valor acrescentam uma nova dimensão à arquitetura de CORBA,
que antes suportava somente chamada por referência. Como objetos de CORBA convencionais,
estas entidades têm estado e métodos; eles não têm (tipicamente) referências de objeto e são
invocados em
processos como objetos de linguagem de programação. Só quando eles são
incluídos em listas de parâmetro de invocação de CORBA que eles mostram seu talento, por
empacotar o estado deles no contexto de envio, mandando para o contexto receptor, criando lá
um exemplo corrente do objeto, e povoando ele com o estado transmitido. Freqüentemente usado
para representar nós em árvores binárias, foram especificados tipos de valores e implementados
para representar fielmente esta importante construção. Esta especificação dá ao CORBA a
capacidade do Java serializable, e é extensivamente usado no mapeamento inverso e modelo de
componente.
3.2 - Componentes de CORBA e CORBA Scripting
O CCM leva os serviços fundamentais que se usa regularmente - persistência, transações,
segurança e notificação - se combina com o POA, e embrulha todas estas ferramentas em
interfaces de alto nível, que correspondem aos padrões que os programadores experientes usam
para codificar projetos e aplicações para Internet.
Isto significa que:

Aplicações de CCM são muito compactas. Elas usam códigos pequenos , e o pouco
que é requerido é totalmente dedicado à programação comercial;

Funções da infra-estrutura - armazenando dados, enquanto ativa e desativa os
servidores, são terminadas e codificadas automaticamente muito bem;

Serão construídas implementações de CCM ao redor de uma infra-estrutura de força
industrial escrita por especialistas, e serão afinados para desempenho ótimo em
ambientes árduos, inclusive a Internet. Quando esta infra-estrutura roda sua aplicação
de CCM em seu ambiente afinado, você adquire os benefícios automaticamente – alto
processamento, grande desempenho, robustez - embora você não tenha que escrever
qualquer código de infra-estrutura, ou até mesmo codificar serviços de interfaces
POA CORBA.
9
As quatro partes principais do CCM são:

Um modelo que apresenta funcionalidade comum - transações, segurança,
persistência - para o programador de alto nível que usa linguagens declarativas e,
opcionalmente, ferramentas visuais;

Um ambiente de container que empacota transações e segurança, somando
persistência e manipulação de evento;

Integração com Enterprise JavaBeans
Modelos de funções de componente são empacotados e apresentaram aos programadores
de alto nível de abstração o que são os serviços abertos de CORBA. São declaradas interfaces de
componentes usando adições recentemente padronizadas na OMG IDL. Componentes declaram
seu estado persistente usando Persistent State Definition Language (PSDL, um grande feito da
OMG IDL), definido no novo PSS. Programadores usam Component Implementation Definition
Language (CIDL, uma extensão de PSDL) para declarar algum comportamento do componente.
Produtos de CCM usam estas declarações para gerar código para partes da implementação.
Finalmente, um idioma de configuração baseado em XML, amarra componentes e os configura
para instalações individuais. Estes idiomas novos trabalham a níveis mais altos de abstração que
CORBA e os serviços de CORBA, os programadores empresariais podem escrever projetos - e
aplicações voltadas à Internet com menos ajuda de peritos de infra-estrutura. Além disso,
algumas linguagens foram projetadas para serem gerados através de ferramentas visuais.
Um objetivo do CCM é permitir escrever aplicações distribuídas que misturam
componentes de CORBA que rodam em servidores de componente CORBA com EJBs que
rodam em servidores baseados em tecnologia EJB. Isto permite para os programadores criarem
uma aplicação reutilizando componentes existentes de qualquer tipo. Para acomodar EJBs, o
CCM define dois níveis de containers e conformance: o container de nível básico é transacional e
seguro, e provê persistência simples; sua definição corresponde quase às características de EJB
1.1. Para fazer isso o container de nível estendido soma persistência a muitos segmentos,
interfaces múltiplas e navegação. A especificação cobre tudo sobre os vários modos que os
clientes de CORBA podem interagir com EJBs e como os clientes de Java podem interagir com
componentes de CORBA. Sendo que todo container apresenta serviços para componentes usando
o mesmo grupo de interface padrão, aplicações de componente são portáteis para qualquer
vendedor. A nível 2 o container soma mais do PSS e um subconjunto de serviço de notificação.
10
Não é necessária a uma implementação de container fornecer seu próprio serviço de persistência,
a especificação assume que os produtos de CCM usarão qualquer padrão PSS standard, e que seu
administrador local comprará e instalará um. Claro que, os vendedores são livres para empacotar
PSS e CCM juntos, se eles quiserem. Container de nível 1 têm que incluir transação e apoio de
segurança, porém, container de nível 2 têm que adicionar seu próprio evento de controle de
capacidade.
Componentes de CORBA estendidos suportam interfaces múltiplas. O CCM define
interfaces, providas pelo container, que permitem uma aplicação de cliente navegar entre eles.
Estes clientes não podem tirar proveito da natureza do componente da implementação, mas
podem invoca-los como um componente CORBA normal sem qualquer dificuldade.
Arquivos de configuração contêm informação sobre eventos emitidos e consumidos por
componentes, pelo menos ao nível estendido. Containers constroem canais para os eventos e os
transmitem em tempo de execução. Desde que as aplicações de CCM se consistam em vários
tipos de componentes, o container também terá que conectar uma invocação através de um tipo,
para uma interface em outro tipo; isto também é especificado no arquivo de configuração e
processo de configuração de tempo de instalação. A configuração do arquiva usa formato XML.
Também há uma especificação de linguagem de script, que traçará várias linguagens de
script ao CCM. Isso resulta em outro modo para juntar componentes em aplicações, além das
ferramentas de baseadas em XML descritas no CCM.
11
Conclusão
A evolução de um conceito bem definido como o CORBA, permite a nós, construtores de
sistemas, resolver as necessidades reais de um ambiente coorporativo. A união de forças dos
vários recursos distribuídos ao longo de um ambiente heterogêneo, pode ser considerada a melhor
forma de se gerenciar informações e compartilhar todo o tipo de dado, seja ele informativo,
gerencial, ou até mesmo dados abstratos de software.
A forte presença da Internet em qualquer lugar que se vá, fez com que o padrão CORBA,
antes pensado para ambientes de rede mais restritos, jogasse toda sua força e funcionalidade na
grande rede. A evolução de CORBA em integrar-se a Java, juntamente com as novas
funcionalidades que essa união proporciona, nos ajuda a conectar sistemas e acessa-los de
qualquer lugar.
O modelo de interoperabilidade sugerido pela arquitetura CORBA vai cada vez mais
proporcionar que empresas criem softwares que poderão se complementar. Elas podem unir
esforços e criar soluções para seus clientes que não serão mais vistas como "a solução" e sim
como parte de uma solução mais completa.
Em sistemas de gestão empresarial por exemplo, os clientes podem estar conectados com
seus fornecedores o tempo todo, buscando melhores cotações e automaticamente gerando ordens
de compra, sem precisar de intermediários, telefonemas, vendedores, tudo pode ser feito
diretamente pela comunicação entre os diversos sistemas de informação.
12
Bibliografia
SIEGEL, Jon. CORBA – Fundamentals and Programming. New York: Wiley
MOWBRAY, Thomas J.; RUH, William A. Inside CORBA – Distributed Object Standards
and Applications. ; Addison Wesley
RICCIONI, Paulo R. Introdução a Objetos Distribuídos com Corba. Florianópolis: Visual
Books
Java Developer’s Journal, disponível em http://www.biztool.com/magazines/java
Banco de Dados e Corba, disponível em http://www.corba.hpg.ig.com.br/home.html
Corba 3 Realease Info, disponível em
http://www.omg.org/technology/corba/corba3releaseinfo.htm
Arquitetura Corba, disponível em http://www.ic.unicamp.br/~ra007293/corba/corba.html
Overview of CORBA, disponível em http://www.cs.wustl.edu/~schmidt/corba-overview.html