IMPLEMENTANDO APLICAÇÕES DISTRIBUÍDAS UTILIZANDO CORBA:

UM ESTUDO DE CASO VOLTADO À ÁREA DE BANCO DE DADOS

Jorge Alberto - Graduado em Processamento de

Dados pelo Cento Universitário de Goiás e Pós-
Graduando em Orientação a Objetos e Internet
pelo Centro Universitário de Goiás - Uni-
ANHANGÜERA

RESUMO:

PALAVRAS-CHAVE: Objetos Distribuídos; CORBA; Banco de Dados.

1. INTRODUÇÃO

O constante aumento na capacidade de processamento dos equipamentos

atuais, conjugado ao crescimento das redes de computadores, tem contribuído cada
vez mais para o desenvolvimento de aplicações distribuídas. Devido a isso, cada dia
mais, as empresas passam a utilizar essa tecnologia com o objetivo de acabar com
a forte concentração de processamento centralizado (arquitetura cliente/servidor), de
tal modo que os objetos distribuídos surgiram com o objetivo de suprir algumas
deficiências dessa arquitetura.
Com o crescimento de usuários acessando sistemas via internet, as
empresas estão sendo obrigadas a criarem ambientes que permitam o acesso
rápido de suas informações a seus usuários.
Estaremos nesseDeste modo, este trabalho apresenta trabalho
apresentandouma proposta de uma arquitetura, CORBA, que utiliza os conceitos de
Objetos Distribuídos, cuja apresentação possibilitará a análise dos resultados em um
estudo de caso utilizando uma aplicação em um servidor de Banco de Dados.

2. REFERENCIAL TEÓRICO

1
 O referencial teórico ora apresentado consiste em teorizar sobre Objetos
Distribuídos e CORBA, e descrever os resultados de um estudo de caso voltado à
área de banco de dados.

2.1. OBJETOS DISTRIBUÍDOS

Segundo Lewandowski, (1998), os objetos distribuídos surgiram através da

união de duas grandes tecnologias: sistemas distribuídos e a orientação a objetos.
Com o surgimento dos objetos distribuídos novos conceitos na construção de
aplicativos foram adotados, substituindo os conceitos tradicionais de construção de
softwares pelo uso de objetos distribuídos interativos.
Objetos distribuídos são entidades independentes que encapsulam dados e
possuem uma série de operações agindo sobre estes dados. As operações
sustentadas por um objeto (métodos) criam instancias de dados. Uma coleção de
objetos formam classes. As classes agem como um modelo que descreve o
comportamento dos objetos.
Os objetos tornam mais fáceis a construção e a manutenção de softwares,
pois fornecem facilidades que nos permite separarmos os dados e as
funcionalidades de outras partes de um sistema.
Os objetos distribuídos possuem as seguintes propriedades: o
encapsulamento, o polimorfismo e a herança.
Um objeto encapsulado administra seus próprios recursos, e limita a
visibilidade e o acesso ao mundo exterior. O acesso dos dados ou métodos por
outros objetos ou aplicativos é permitido através da publicação de interfaces
publicas. As instancias de dados em um objeto, podem ser declarados como
privados ou públicos. As instancias de dados privados, podem ser acessados
somente pelos métodos da classe. Por outro lado, métodos e instancias de dados
publicas, são acessados por qualquer objeto.
Segundo Orfali; Harkey; Edwards, (1996), Polimorfismo é a capacidade de
diferentes métodos realizarem diferentes ações, dependendo da classe que estão
implementadas. Através das características de polimorfismo é possível aumentar o
nível de abstração do software, pois é necessário se preocupar apenas com as
ações e não com a sua implementação. O polimorfismo faz com que objetos em

2
diferentes classes recebam a mesma mensagem e mesmo assim, tenham formas
diferentes de ação.
Segundo Orfali; Harkey; Edwards, (1996), Herança é o mecanismo que
permite a criação de subclasses ou classes derivadas. Através da herança, uma
subclasse passa a herdar todos os atributos e métodos de sua classe. Um objeto
pode suportar herança simples ou múltipla, dependendo do modelo do objeto
utilizado. Em uma herança simples, uma classe possui apenas uma subclasse,
enquanto que na múltipla podem ter várias.
Estas três propriedades da orientação a objetos fornecem a base para a
criação, o agrupamento e a reutilização dos objetos.

2.1.1. COMPONENTES
Quando falamos em objetos distribuídos, estamos falando sobre
componentes de softwares independentes. Os componentes são, basicamente,
objetos comuns com a capacidade de fornecer informações ou alterar suas
funcionalidades em tempo de execução.
Segundo Lewandowski, (1998), Um componente, em um sistema de objetos
distribuídos, é um objeto auto- gerenciável e independente, que funciona em
múltiplas plataformas.
A utilização de componentes, na construção de softwares, ajuda-nos a
acelerar o desenvolvimento de sistemas e leva-nos a criar aplicações modulares de
fácil aprendizado.
O uso de componentes foi um grande avanço na direção do reaproveitamento
de código, sendo eles suficientemente poderosos para aumentar a produtividade do
desenvolvimento de sistemas para as empresas. Nesse caso uma empresa pode
adquirir componentes com um código já testado e pronto para uso, além da
facilidade de adaptação.

2.1.2. BENEFÍCIOS
Resumindo, um componente é um pedaço de software reutilizável e auto
-gerenciável, independente de qualquer aplicação.

3
 A tecnologia de objetos distribuídos tem trazido importantes benefícios para
os sistemas cliente/servidor. A abstração, a modularidade e a reusabilidade, são
apenas alguns exemplos desses benefícios.
 Abstração: Significa que uma aplicação pode funcionar sem o
conhecimento dos detalhes de um serviço de qualidade (QoS) fornecidos
ou nem mesmo saber se está rodando sobre ATM (Asynchronous Transfer
Mode)1 ou sobre TCP/IP. Recursos de localização e nomes estão
associados a abstração.
 Modularidade: Um objeto é uma entidade independente
cujos serviços, projetados separadamente dos objetos, podem ser
invocados por diferentes clientes. A modularidade permite que sejam feitas
alterações em uma parte do código, sem afetar o restante da aplicação.
Arquiteturas avançadas oferecem aos usuários finais a capacidade de
adicionar componentes, permitindo um ajuste pessoal na aplicação.
 Reusabilidade: A reusabilidade é possível através de
bibliotecas de auxílio a serviços e facilidades dos objetos fornecidas pelas
plataformas de objetos distribuídos. Eles oferecem funções como
segurança, gerenciamento do ciclo de vida dos objetos, serviços de
nomes, serviços de notificação e várias facilidades especiais que seriam
escritas dentro das aplicações repetidamente se as bibliotecas não
existissem.
Os Objetos distribuídos surgiram com o propósito de revolucionar a
construção de sistemas cliente/servidor escaláveis.
A indústria da computação esta trabalhando no desenvolvimento de padrões
para melhorar cada vez mais a interoperabilidade e para determinar um ORB
(Object Request Broker)2 comum, com o objetivo de melhorar o desenvolvimento de
sistemas cliente/servidor em ambientes heterogêneos.
Devido aos grandes avanços da tecnologia e das vantagens fornecidas pelos
objetos distribuídos, o desenvolvimento de sistemas cliente/servidor com objetos
distribuídos estão tendo grande aceitação no mercado.

1
Modo de Transferência Assíncrona
2
Analisador de Requisições a Objetos

4
 Desenvolver sistemas cliente/servidor usando tecnologia que suporte objetos
distribuídos fornece interoperabilidade entre linguagens e plataformas, permitindo
um considerável aumento da sustentabilidade e adaptabilidade dos sistemas.
É indiscutível os inúmeros benefícios que teremos com o uso dos objetos
distribuídos em sistemas cliente/servidor. É claro que esta tecnologia não resolve
todas as nossas necessidades, pois junto com a evolução da tecnologia nossos
problemas e nossa demanda também evoluíram. Resumindo, para conseguirmos
tirar o máximo proveito de todas as vantagens desta tecnologia, é essencial a
escolha apropriada do modelo de objetos distribuídos e de uma boa linguagem de
programação.

2.2. CORBA
Segundo Lewandowski, (1998), CORBA (Common Object Request Broker
Architecture)3 é um sistema de objetos distribuído robusto, que permite objetos
serem escritos em diferentes linguagens, serem compilados por diferentes
compiladores e comunicarem-se através de um protocolo de mensagens
padronizados. CORBA permite o mais alto nível de transparência e de
interoperabilidade entre os objetos distribuídos.
A primeira especificação de CORBA foi criado em 1991 pela OMG (Object
Management Group)4 e em 1994, surgiu a segunda versão do CORBA, com uma
evolução no padrão dos objetos distribuídos rumo a interoperabilidade e a
integração entre aplicações implementadas em diferentes linguagens e diferentes
plataformas. A idéia era que os objetos de uma empresa, possam ser capazes de se
comunicar e cooperar com objetos de outras empresas.
O maior objetivo da criação da estrutura CORBA, foi a de permitir a
comunicação entre objetos, que vivem em ambientes heterogêneos e distribuídos,
de forma eficiente e transparente, ou seja, uma aplicação cliente, pode estar
localizada em qualquer lugar do planeta, que os objetos CORBA vão ser acessados
através da invocação de um método remoto, utilizando toda a estrutura da figura
abaixo. A localização dos objetos é completamente transparente para a aplicação
cliente. O que a aplicação cliente precisa realmente conhecer para acessar um
objeto CORBA, são os detalhes da interface dos objetos.

3
Arquitetura Comum para Agente de Requisição de Objetos
4
Grupo de Gerência de Objetos

5
 Cliente Servidor

ORB Rede ORB

Figura 1: A Arquitetura CORBA (Fonte: DEMARTINI, 2002, p. 11)

2.2.1. ESTRUTURA CORBA

O elemento principal de CORBA é o ORB, responsável por estabelecer um
relacionamento cliente/servidor entre os componentes da aplicação, passando os
parâmetros necessários e recebendo os valores resultantes da requisição.
O ORB fornece muitos benefícios para que possamos desenvolver sistemas
cliente/servidor com objetos distribuídos de forma consistente. Segue abaixo alguns
dos benefícios fornecidos pelo ORB.
• Métodos de invocação estática e dinâmica, permitindo ao
desenvolvedor optar pela simplicidade ou pela flexibilidade.
• Interligação com linguagens de alto nível devido a separação que
CORBA faz entre a interface e a implementação, possibilitando a
invocação dos objetos através de linguagens de alto nível, como C, C+
+ e java.
• Auto descrição dos sistema, graças a um repositório de interfaces
fornecido pelo CORBA, permitindo a busca de informações a respeito
das funções e parâmetros fornecidos pelo servidor, em tempo real.
• Transparência local e remota.
• Transação e segurança embutida.
• Mensagens de polimorfismo.
Outro item importante é a IDL (Interface Definition Language)5. Segundo
Lewandowski, (1998), a função da linguagem de definição de interface do CORBA é
especificar um serviço fornecido por um objeto.
5
Linguagem de Definição de Interface

6
 A IDL foi projetada para ser completamente independente das linguagens de
implementação, ferramentas, sistemas operacionais e outros fatores que
normalmente afetam a interoperabilidade.
As interfaces das implementações de objetos escritos em IDL, especificam os
parâmetros necessários de entrada e de retorno das operações sendo puramente
declarativa. A IDL não possui definição de variáveis e nem estrutura de códigos.
Através da interface especificada pela IDL, na implementação do objeto, que o
cliente executa uma chamada, podendo ser uma invocação estática ou uma
invocação dinâmica.
Em uma invocação estática, todas as chamadas do cliente para a
implementação do objeto já estão disponíveis no código do cliente. Para o cliente a
chamada se parece como se estivesse invocando simplesmente um método local.
Na realidade, o ORB direciona o método invocado para o objeto servidor apropriado.
A invocação dinâmica é feita através do componente com auxílio de um
repositório de interfaces. Invocação dinâmica significa que o cliente pode determinar
em tempo de execução a interface de um objeto, descobrir suas operações, número
e tipo de parâmetros, preencher as informações necessárias para executar a
requisição e fazer a invocação.
Para a implementação do objeto, não importa o tipo de invocação usada pelo
cliente, ou seja, não é preciso saber se o método invocado foi estático ou dinâmico.
O cliente executa uma requisição tendo acesso a uma referência para objeto e ao
nome da operação desejada. O ORB localiza a implementação do objeto, transmite
os parâmetros e transfere o controle através dos skeletons (estrutura). Ao executar a
requisição, a implementação do objeto pode obter alguns serviços do ORB através
do Object Adapter (Adaptador de Objeto). Quando a requisição é terminada, o
controle e os valores de saída são retornados para o cliente.
Um repositório de interfaces do CORBA é um banco de dados que armazena
todas as definições dos objetos, permitindo aos componentes, obterem e
modificarem a interface dos objetos registrados para que tenham acesso. O
repositório de interfaces contém todas as definições de IDL, que descrevem os
atributos, operações, tipos de usuários especificados, e exceções suportados pelo
servidor de objetos.
7
 É através do repositório de interfaces que podemos obter em tempo de
execução informações referente às IDL’s. Estas informações são utilizadas pelo
ORB para realizar invocações dinâmicas a objetos remotos. Através das
informações disponíveis no repositório de interfaces, um programa tem a capacidade
de encontrar um objeto remoto mesmo sem ter conhecimento de sua interface, seus
métodos e parâmetros, e sua forma de ativação.

2.2.2. SERVIÇOS E FACILIDADES CORBA

No desenvolvimento de aplicações orientada a objetos, o padrão CORBA
oferece um pacote de serviços fornecidos a nível de sistemas, com o objetivo de
facilitar o trabalho do projetista da aplicação, permitindo a ele total concentração de
esforços no desenvolvimento dos objetos, sem a preocupação com os serviços a
nível de sistemas. Esses serviços podem ser vistos como um complemento e um
aumento das funcionalidades do ORB.
As facilidades CORBA fornecem um conjunto de funções genéricas, que
podem ser configurados para as necessidades de ambientes específicos, voltados
mais para o nível de aplicação.
De acordo com Riccioni, (2000), a OMG divide as facilidades CORBA em dois
aspectos: facilidades horizontais e as facilidades verticais. As facilidades horizontais
são utilizadas por várias aplicações, independente da área de aplicação, e são
divididas em quatro categorias: interface do usuário; gerenciamento de sistema;
gerenciamento de informação e gerenciamento de tarefa. Já, as facilidades verticais
são utilizadas em áreas de aplicações específicas, a exemplos de imagens;
supervias de informação; manufatura integrada por computador; medicina;
contabilidade; simulação distribuída, etc.

8
 Figura 2: A Arquitetura CORBA (Fonte: DEMARTINI, 2002, p. 11)

3. ANALISE DE DADOS

4. CONCLUSÃO

9
REFERÊNCIAS BIBLIOGRÁFICA

CÔRTES, Sérgio da Costa, Utilizando CORBA em ambiente de Múltiplos Bancos

de Dados. Trata-se de um artigo publicado pelo Côrtes, o que colocar?????

DEMARTINI, Fabiano. Aprenda Rápido: CORBA em Delphi 6. Santa Catarina -

Visual Books, 2002.

LEWANDOWSKI, Scott M. Frameworks for Component-Based Client/Server

Computing. ACM computing Surveys, Vol. 30, No. 1, 1998.

MONTEZ, Carlos. Um Modelo de Programação para Aplicações de Tempo Real

em Sistemas Abertos. Monografia (Doutorado), DAS, UFSC, 2002.

ORFALI, Robert; HARKEY, Dan; EDWARDS, Jeri. The Essential DISTRIBUTED

OBJECTS Survival Guide. Jonh Wiley, New York, 1996.

PAGNUSSAT, Tânia Maria. Modelo CORBA. Monografia (Conclusão da disciplina

Tópicos Avançados de Tecnologia da Informação), UniCEUB, 2000.

RICCIONI, Paulo Roberto. Introdução a Objetos Distribuídos com CORBA. Santa

Catarina - Visual Books, 2000.

10