IMPLEMENTAÇÃO DE UM SERVIDOR UTILIZANDO A ESPECIFICAÇÃO CORBA PARA COMUNICAÇÃO DE DOIS SISTEMAS HETEROGÊNEOS

Prévia do material em texto

5
Centro Universitário de Brasília
Faculdade de Tecnologia e Ciências Sociais Aplicadas
Ciência da Computação
Implementação de um servidor utilizando a especificação CORBA para comunicação de dois sistemas heterogêneos
Karlyson Rodrigues Oliveira
Mariana Fioravanti
Pedro Chagas Pestana
Thiago da Costa Alves
Raphael Duarte Silva
Trabalho de Conclusão da Disciplina Sistemas Distribuídos
Professor: 
Fabiano Mariath D'Oliveira
Brasília, 11 de outubro de 2013
Implementação de um servidor utilizando a especificação CORBA para comunicação de dois sistemas heterogêneos
Trabalho de conclusão de disciplina apresentado como parte das atividades para obtenção do título de Bacharel, do curso de Ciência da Computação da Faculdade de Tecnologia e Ciências Sociais Aplicadas do Centro Universitário de Brasília.
Prof. orientador: Fabiano Mariath D'Oliveira
Brasília, 2013
Resumo
O presente arquivo trata sobre o estudo de caso de desenvolvimento de aplicações distribuídas relacionando as linguagens de programação JAVA e C++ com o Framework CORBA. O objetivo desse estudo limita-se à resolver um problema atual – a heterogeneidade dos ambientes de hardware e software empregados em sistemas distribuídos – com auxílio das especificações CORBA – que possui paradigmas orientado a objetos independentes do sistema – e as linguagens JAVA e C++, para construção do software. Dessa forma, será exemplificada uma solução para um modelo cliente-servidor utilizando a arquitetura e serviços CORBA.
Palavras-chave: JAVA, C++, CORBA, Orientado a Objeto, Sistemas Distribuídos.
Abstract
The current file defines the study case of a distributed application developement using programming languages JAVA and C++ with the Framework CORBA. The direct objective of this study stands to solve an actual problem – the heterogeneity of hardware and software environment linked to distributed systems – with assistance of CORBA specifications – that possesses object-oriented paradigms – and JAVA e C++ languages, to software construction. Therefore, will be exemplified a solution for a client-server model using CORBA’s architecture and services.
Key words: JAVA, C++, CORBA, object-oriented, Distributed System.
Sumário
1 INTRODUÇÃO	6
1.1 Objetivo Geral	7
2 REFERENCIAL TEÓRICO	8
2.1 CORBA – Common Object Request Broker Architecture	8
2.2 OMA – Object Management Architecture	9
2.3 IDL - Interface Definition Language	10
2.4 CCM (CORBA Component Model)	12
2.5 Stubs e Skeletons	13
2.6 Naming Service	13
2.7 IIOP – Internet InterORB Protocol	14
3 DESENVOLVIMENTO	16
3.1 Implementação	16
4 CONSIDERAÇÕES FINAIS	23
Referências bibliográficas	24
INTRODUÇÃO
A biblioteca da faculdade (nome da faculdade) possui um sistema interno que permite realizar consultas de livros on-line, reserva de livros via internet, renovação de empréstimos, controle de devolução de livros, e calculo de multas. Existe outro sistema na faculdade chamado Graduação Online, onde cada aluno acessa sua conta com a matrícula e senha, e visualiza suas frequências, menções, grade horária, planos de ensino enviados pelos professores, emite boletos para pagamento da mensalidade, visualiza e envia mensagens para outros alunos e professores, solicita documentos para secretaria, realiza a matricula e cria processos.
Atualmente, existe a necessidade de o sistema da biblioteca enviar informações para o sistema de Graduação Online. E o mesmo ser capaz de gerar um boleto para o aluno que tiver uma multa a pagar a partir dessas informações, porém esses sistemas estão em linguagens e arquitetura diferentes.
Existem diversos modelos de objetos distribuídos, dentre eles destaca-se o Distributed Component Object Model (DCOM), da Microsoft, e o Common Object Request Broker Architecture (CORBA), do Object Management Group (OMG). A principal característica, que definiu a escolha do CORBA como o framework para resolução do problema, é a independência de sistema operacional e linguagem de programação, enquanto que o DCOM contempla somente o MS Windows NT 4.0, MS Windows 98 ES ou superior.
Neste trabalho pretendemos demonstrar a comunicação remota de dois sistemas heterogêneos, mais detalhadamente utilizando o framework CORBA, criada pela OMG (Object Management Group), que é utilizado para o desenvolvimento de sistemas de software distribuídos baseados na tecnologia de objetos. Essa especificação possibilita que sistemas distribuídos implementados em diversos sistemas operacionais, arquiteturas e linguagens de programação possam comunicar-se, possibilitando que umas coleções de objetos distribuídos heterogêneos possam colaborar de forma transparente. 
Neste presente trabalho temos o objetivo de explorar as técnicas de programação para comunicação remota entre sistemas distribuídos e heterogêneos utilizando o framework CORBA. E para isso, utilizaremos um estudo de caso da faculdade (nome da faculdade) que precisa fazer a comunicação entre dois sistemas e mostraremos a implementação de uma aplicação simples que faz a comunicação de dois sistemas, um desenvolvido em JAVA e o outro em C++.
Objetivo Geral
O Objetivo geral do trabalho é de explorar as técnicas de programação para comunicação remota entre sistemas distribuídos e heterogêneos utilizando o framework CORBA. E para isso, utilizaremos um estudo de caso de uma faculdade que precisa fazer a comunicação entre dois sistemas e mostraremos a implementação de uma aplicação simples que faz a comunicação de dois sistemas, um desenvolvido em JAVA e o outro em C++.
REFERENCIAL TEÓRICO
CORBA é um padrão que foi definido em 1991 pela OMG (Object Management Group). O padrão CORBA é um sistema que permite a comunicação e trocas de informações das aplicações distribuídas em uma rede sendo executado em qualquer parte da rede ou Internet. [Object Management Group(2004)]. Como principais vantagens são: transparência de acesso aos dados, independência de linguagem e neutralidade de plataforma.
CORBA – Common Object Request Broker Architecture
O CORBA é uma arquitetura de objetos distribuídos desenvolvida pela OMG, que tem como objetivo simplificar a troca de informação entre máquinas que fazem parte de um sistema distribuído. Define um protocolo de interação entre os clientes e os objetos remotos. Atinge-se este objetivo através da sua independência de plataforma e de linguagens de programação. Face à diversidade de software e hardware disponíveis atualmente, o CORBA permite que a comunicação entre os objetos distribuídos seja efetuada corretamente sem a percepção de diferenças no ambiente ou contexto em que se encontram.
De uma forma simples, uma aplicação CORBA é constituída essencialmente por três componentes principais: o Cliente, o ORB (Object Request Broker) e os Objetos Remotos. O ORB é a estrutura mais importante da arquitetura CORBA corresponde à camada de middleware, que tem por função intermediar todas as comunicações e transferências entre o Cliente e os Objetos Remotos. Esse middleware possibilita que as transações sejam transparentes para cada uma das partes envolvidas durante todo o processo de comunicação.
Para conceber o conceito de Object Request Broker (ORB), necessita-se da análise de cada palavra isoladamente:
Object– Em CORBA, um objeto é identificado de forma única através de uma referência a um objeto remoto. Todos os objetos remotos estão disponíveis aos clientes através da sua interface que descreve um conjunto de operações que podem ser invocados pelos clientes. O uso de uma interface permite ocultar ao cliente os aspectos relacionados com a implementação dos objetos. Mudanças na implementação de um objeto não implicam necessariamente, uma alteração na sua interface, e não implicam desta forma, qualquer alteração no cliente.
Broker– É a entidade que atua como um mediador para outras entidades. Em CORBA, os clientes fazem pedidos aos objetos remotos. Estes pedidos são mediados e tratados pelo broker que se encarrega de transportá-losdos clientes até aos objetos remotos e de retransmitir os resultados da invocação até aos clientes.
Request– É um pedido efetuado por um cliente. Um cliente realiza as suas tarefas obtendo referências para objetos remotos para posteriormente invocar operações sobre estes. Os objetos referenciados podem estar na mesma maquina que o cliente ou estarem localizados noutras maquinas. A chamada de um método de um objeto remoto, para o programador, não difere da chamada de um método local. O Basic System também possui esta característica. Se uma tarefa comunica com outra através de um functional destination então é desconhecida a localização da outra tarefa. Pode estar localizado no mesmo nó como pode estar em um nó remoto e o meio de comunicação (TCP/IP, USB, RS-232, X.25, etc.)também não influencia o comportamento da tarefa.
A partir destes três conceitos, podemos verificar que o ORB atua como um mediador, que gere a interoperabilidade entre os clientes e os objetos remotos que disponibilizam serviços aos seus clientes. Por outras palavras, o ORB é uma camada de middleware que coordena uma infra-estrutura de objetos distribuídos.
OMA – Object Management Architecture
A OMA (Object Management Architecture), foi criada pelo OMG, com o objetivo de integrar as aplicações baseadas em Objetos distribuídos. Sua estrutura é baseada essencialmente em dois elementos: o Modelo de Objeto, que define o Objeto que será distribuído pelo sistema heterogêneo e o Modelo de Referência, que define as características da integração destes Objetos.O RFP (Request for Proposal) é utilizado para que os Modelos de Objetos e de Referência possam ser compatíveis com especificações anteriormente utilizadas e,com isso tornar possível a construção de sistemas de objetos distribuídos interoperáveis em sistemas heterogêneos. CORBA possui toda sua estrutura baseada na arquitetura OMA. Esta define a comunicação entre os Objetos distribuídos através de quatro elementos:
Objetos de Aplicação: São os Objetos criados pelo usuário, que possuem características definidas de acordo com os seus objetivos. Eles também são tidos como os usuários finais de toda a infraestrutura CORBA.
Facilidades Comuns: São componentes definidos em IDL que fornecem serviços para o uso direto das aplicações de Objetos, definem regras de integração para que os componentes possam colaborar efetivamente. Estes estão divididos em duas categorias que são horizontal e vertical. 
Serviços Comuns: São serviços que possibilitam a implementação e utilização de Objetos. Eles definem uma estrutura de Objetos de baixo nível, que ampliam as funcionalidades do ORB, sendo utilizados para criar um componente, nomeá-lo e introduzi-lo no ambiente.
ORB: É o elemento que permite que Objetos emitam solicitações em um ambiente distribuído e heterogêneo, de forma transparente.
IDL - Interface Definition Language
A linguagem IDL (Interface Definition Language) é usada para descrever as interfaces dos objetos CORBA, sendo puramente declarativa e, portanto, é independente da linguagem de programação utilizada para acessá-la.. Uma definição IDL especifica cada atributo e parâmetro das operações definida em uma interface. Uma interface IDL oferece as informações necessárias para desenvolver clientes que usam operações disponíveis remotamente. Tanto o cliente quanto à implementação de objetos não são escritos em IDL, mas em linguagens de programação para os quais foram definidos os mapeamentos dos conceitos em IDL. 
O mapeamento de um conceito em IDL para uma construção de uma linguagem destino dependerá das facilidades existentes.
A gramática de IDL é um subconjunto de C++ com construções adicionais para os mecanismos de requisições de operações. Ela permite a definição de tipos, de constantes, de exceções e de módulos, além de prover suporte aos recursos de pré-processamento para inclusão de arquivos e substituição de macros.
Toda declaração de interface contém um cabeçalho e um corpo. O cabeçalho é composto por um identificador que o nomeia e por uma especificação opcional de herança. O identificador define um nome do tipo interface, sendo uma referência para o objeto que suporte tal interface. O corpo de uma interface pode conter declarações: de constantes, de tipos, desde que não sejam novas interfaces, de exceções, de atributos, e de operações, incluindo o nome da operação, seu modo de execução, os tipos de seus parâmetros e do dado de retorno. A assinatura de uma interface é caracterizada por suas operações e atributos. Entretanto, uma definição de atributo é logicamente equivalente à declaração de um par de operações de acesso: um para a leitura e outra para escrita.
As especificações em IDL são fortemente tipadas, pois definem o tipo de retorno das operações, o tipo dos parâmetros e dos atributos. A figura 1 exibe os elementos que constituem a estrutura da interface IDL.
Módulos: Identificado pela palavra chave module e serve para agrupar um conjunto de interfaces. Uma declaração de módulo pode incluir: declarações de tipos; declarações de constantes, declarações de exceções, declarações de interfaces e outros módulos.
Atributos: Descrevem propriedades de um objeto e por default podem ser consultados e modificados. Atributos que não podem ser modificados devem ser declarados como read-only.
Interfaces: Uma interface define uma classe de objetos CORBA. Ela especifica as instâncias de serviços que uma classe possui, seus atributos e as exceções que podem gerar para indicar quando uma operação não teve sucesso.IDL permite herança múltipla, o que significa que uma interface pode ser derivada de uma ou mais interfaces.
Operações: O conjunto de declarações de operações em uma interface define os serviços que um objeto é capaz de executar. Uma operação define os parâmetros de entrada e saída necessários para um certo serviço. O tipo de uma operação é o tipo do resultado de sua execução.
Tipos de Dados: Os tipos de dados são usados para descrever os valores aceitáveis para parâmetros, atributos, exceções e valores de retorno. CORBA classifica os tipos de dados em duas formas: básico e construídos. Os tipos dedados básicos do modelo CORBA são mostrados na tabela 3, com a sua sintaxe em IDL e descrição. Da mesma forma, são apresentados os tipos construídos ou estruturados na tabela 4.
Figura1:Estrutura da Interface IDL.
	
	Tipo
	
	Sintaxe
	
	Descrição
	Inteiro
	Short
	Número inteiro de 32 bits com sinal
	Inteiro
	Long
	Número inteiro de 64 bits com sinal
	Inteiro
	unsigned short
	Número inteiro de 32 bits sem sinal
	Inteiro
	unsignedlong
	Número inteiro de 64 bits sem sinal
	Ponto flutuante
	Float
	Número de ponto flutuante de 32 bits (IEEE)
	Ponto flutuante
	Doublé
	Número de ponto flutuante de 64 bits (IEEE)
	Caracteres
	Char
	
	Booleano
	Boolean
	Tipo booleano com valores “TRUE”e “FALSE”
	Octeto
	Octet
	Tipode dado opaco de 8 bits que garante que
nenhuma	conversão	será	feita	durante	a	sua transmissão entre os sistemas
	Genérico
	Any
	Tipoque pode representar qualquer tipo básico ou
estruturado.
Tabela1: Tipos básicos IDL.
	
	Tipo
	
	Sintaxe
	
	Descrição
	Enumerado
	enum<identifier>
	Lista ordenada de identificadores
	Estrutura
	struct<identifier>
	Estrutura ordenada de pares
	União
	union<identifier>
	Umdiscriminanteseguidodeumainstânciadeum
tipo apropriado para o discriminante.
	Vetor
	Array
	Vetor de tamanho fixo de valores de um único tipo
	seqüência
	sequence	<<type>,
<const>>
	Vetordetamanhovariáveldevaloresdeumúnico tipo,sendo que o tamanho da seqüênciaé
determinado em tempo de execução.
	Vetor de caracteres
	String
	Vetor de caracteres de tamanho variável.
Tabela2:Tipos Estruturados IDL.
CCM (CORBA Component Model)
CCM é uma definição introduzida com a versão 3.0 do CORBA que especifica como deve ser um framework de aplicação para os componentes CORBA.
CCM utiliza um container para desenvolvimento dos componentes CORBA, que disponibilizadiversos serviços utilizados por estes componentes, como persistência de dados, gerenciamento de transações, autenticação, entre outros. Isso reduz a complexidade de programação dos componentes, já que diversas funcionalidades necessárias já estarão inclusas no container.
Os componentes citados são as aplicações capazes de prover e aceitar serviços, sobre os quais o CMM cria uma abstração através de interfaces chamadas ports – assim como os beans representam uma abstração dos componentes no Enterprise JavaBeans – sem a restrição à linguagem JAVA.
Stubs e Skeletons
Definem a relação entre o Cliente e o Objeto implementando a arquitetura Cliente/Servidor do CORBA, sendo o Stub situado na extremidade do Cliente e o Skeleton na do Objeto. 
O Stub e o Skeleton são criados a partir das definições da compilação da Interface IDL do Cliente e do Objeto. O Stub tem a capacidade de localizar objetos-destino (Proxies) independente do local do objeto – garantindo a transparência nos sistemas distribuídos – e empacotam a mensagem em conjunto ao ORB. Os Skeletons possuem função similar, porém dependem da solicitação recebida pelo ORB para desempacotar a mensagem e entregá-la à implementação do Objeto. 
Utilizando as aplicações do CORBA, tem-se a Invocação Estática: as mensagens são construídas na aplicação Cliente e implementadas na aplicação Objeto (para tanto é preciso conhecer todas as interfaces OMG/IDL dos objetos CORBA invocados). Dessa forma o Stub transforma o que for transmitido pela aplicação Cliente, independente da linguagem, para trafegar o dado pela rede. E o Skeleton transforma o que foi recebido para a linguagem de programação implementada no Objeto. Porém essa invocação necessita de parar o sistema ou realizar nova compilação para cada objeto criado.
Outra forma mais producente, flexível e ágil chama-se Invocação e Envio Dinâmico – permite que os objetos criados nas duas compilações (Stub e Skeleton) sejam acessados –. São duas interfaces suportadas pelo CORBA: DII (Dynamic Invocation Interface) – referente ao Stub – e DSI (Dynamic Skeleton Interface) – referente ao Skeleton – fornecidas diretamente do ORB e presente em todos os Clientes e Objetos criados. Essa invocação explora o conceito de transparência, pois a implementação desconhece se a requisição é realizada em um Stub estático ou dinâmico.
Naming Service
É um serviço padrão de aplicações CORBA, definido pela OMG, cuja função resume-se em associar nomes abstratos aos objetos CORBA em seus aplicativos e possibilita um cliente encontrá-los através dos nomes correspondentes. Um serviço definido como simplificado e útil.
A associação entre o objeto CORBA e o servidor se dá através do Naming Service: para obter uma referência do objeto, um cliente solicita um Naming Service para que possa procurar um objeto no servidor. O Naming Service fornece interfaces definidas em IDL que permitem aos servidores vincular nome aos objetos específicos e aos clientes, encontrar a localização do endereço do objeto.
O Naming Service mantém um banco de dados de nomes e os objetos em associação, método conhecido por binding. As interfaces IDL do Naming Service fornecem operações para acessar o banco de dados de bindings, como exemplo: criar novos bindings, resolver nomes e deletar bindings existentes.
No CORBA Naming Service, os nomes podem ser associados a dois tipos de objetos: ao Naming context ou ao application object. O Naming context é um objeto do Naming Service dentro do qual é possível resolver os nomes de outros objetos. Estes são organizados um gráfico de nomes, que podem formar uma hierarquia de nomenclatura muito semelhante ao de um sistema de arquivos. Usando essa analogia, um nome vinculado a um Naming context corresponderia a um diretório e um nome vinculado a um objeto corresponderia a um arquivo.
O nome completo de um objeto, incluindo todos os Naming Contexts associados, é conhecido como Compound Name.  O primeiro componente de Compound Name fornece o nome do Naming context em que o segundo componente é acessado. 
IIOP – Internet InterORB Protocol
Toda a interoperabilidade do CORBA em ambientes heterogêneos e entrega de pacotes pela internet depende do IIOP – Internet InterORB Protocol –, que já está incorporado ao framework. O IIOP é um mecanismo subjacente da tecnologia CORBA gerenciada, transparentemente, pela ORB. Dessa forma não há necessidade de interação do IIOP com programadores/desenvolvedores e o IIOP permite a interação dos programas externos sejam executados, também de forma transparente, no framework. 
A especificação IIOP define as regras de formatação de dados pelo CDR – Common Data Representation – adaptando os tipos de dado suportados pelo CORBA IDL, definindo tipos de mensagens suportadas pela semântica ORB definida no núcleo do CORBA. O CDR e as formatações de mensagens constituem o GIOP – General InterORB Protocol –, mensagens que podem ser enviadas virtualmente por qualquer protocolo de transporte, tais como TCP/IP, Novell SPX, SNA protocol. Porém a conexão mais segura verifica-se somente com a interoperabilidade dos produtos ORB, a especificação IIOP requer o envio de mensagens GIOP seja efetuado TCP/IP – por possuir o padrão de orientação de conexão de protocolo de transporte para internet –.
Os objetos publicam as suas identidades e localização em forma de referência a objetos. Dessa forma, o CORBA refere-se ao formato de referência acima do IIOP, o IOR – Interoperable Objetct Reference –, que contem um ou mais perfil, que, por sua vez, possui um protocolo particular para contato e requisição do cliente ao objeto em questão. Novamente existe o conceito de transparência, pois cada IOR necessita de um perfil IIOP e a partir do momento que a referência é efetuada, qualquer compilador CORBA localizará o objeto e enviará a requisição específica do cliente. O IIOP possui um perfil que contêm o endereço de internet do objeto do servidor e a chave usada pelo servidor para achar o objeto específico descrito na referência de objetos. As referências de objetos podem ser transformadas em strings de caractere e publicá-la arbitrariamente. Qualquer compilador CORBA pode converter a string em IOR e localizar o objeto invocado por meio desse.
A plataforma independente do CORBA/IIOP é um dos fatores mais importantes. A interoperabilidade do CORBA ORB torna o CORBA/IIOP a solução ideal para Internet, especialmente considerando a vastidão e disparate dos hardwares e softwares implantados. A independência da plataforma promove a utilização de somente um fornecedor sem necessitar de refazer sistemas e redes de hardware e software. Ou seja, é um negócio de instalação de base que permite a compatibilidade com a maioria dos sistemas em uso – precisando de modificações simplórias –.
Resumidamente o protocolo IIOP permite a utilização de qualquer ambiente para o programador definir e invocar qualquer operação dependendo dos parâmetros de input e output. Enquanto a aplicação aderir àespecificação CORBA, a transparência do IIOP permitirá a comunicação, provendo somente um protocolo para interoperabilidade entre a empresa e a Web. Sua interconectividade de objetos ou ORB estende a execução dos programas ligados ao ambiente de rede à criação remota na Web em Desktops, gerando maior ligação e flexibilidade que o HTTP – HiperText Transport Protocol –. Em sintonia com os applets de execução do JAVA, o IIOP se torna referência para desenvolvimento de aplicações de sistemas distribuídos para Web.
DESENVOLVIMENTO
Demonstraremos a implementação de um sistema envolvendo duas linguagens de programação, JAVA e C++, que irá, resumidamente, vincular o sistema da biblioteca de uma faculdade com a impressão do boleto de empréstimo de livros. A comunicação entre os sistemas desenvolvidos em JAVA e C++ dependem do processamento dos dados no framework CORBA. Este trabalha com a parte de comunicação de Middleware – camada intermediária de intercomunicação dos objetos do aplicativo e módulos de comunicação e referência remota – com foco em desenvolvimentode aplicações no nível de Interface.Para tanto se necessita elaborar a estrutura de biblioteca de aplicações e objetos do CORBA e definir os Stubs e Skeletons.
Implementação
A seguir será mostrada uma aplicação simples utilizando uma implementação do CORBA, utilizando o modelo cliente-servidor.
A aplicação trata-se de um servidor de gerenciamento de boleto da faculdade (Nome da Faculdade), na qual o aluno pode obter seu boleto após a devolução de um livro com atraso na biblioteca. As implementações do servidor e do cliente, que envia as informações referentes ao boleto, foram feita utilizando a linguagem de programação JAVA. O sistema que o aluno acessa para obter o boleto foi desenvolvido em C++. Essas implementações são mostradas logo abaixo e só foram possíveis através do CORBA, que possui a heterogeneidade de se trabalhar com linguagens diferentes.
Primeiramente temos um arquivo IDL, o skeleton do servidor, que descreve a interface de acesso ao objeto do tipo Boleto. Com isto, qualquer clientesaberá como acessar os serviços prestados pelo servidor. Ele possui o método enviar_boleto (boleto bol), que tem como retorno uma cadeia de caracteres, informando ao objeto que requisitou o método, uma mensagem de confirmação indicando se a comunicação foi ou não bem sucedida. A figura 5.1 mostra umapossível implementação do skeleton do servidor.
Figura 2 - Detalhamento da implementação do Skeleton
Após a definição da interface é necessário que a mesma seja compilada. Para executar a compilação, após toda configuração do ambiente,basta o seguinte comando na linha de comando:
“ idlj -fall tutorial.idl ”
 Através da compilação serão geradas nove classes em JAVA em um subdiretório com o mesmo nome do módulo definido na IDL, no caso: tutorial.
Alguns dos arquivos gerados serão descritos logo abaixo:
gerenciadorBoleto.java: 
Esta interface contém a versão Java da interface “boleto” (boleto.idl). A classe correio.java estende a interface ‘org.omg.CORBA.Object’, para fornecer afuncionalidade dos objetos CORBA.
gerenciadorBoletoHelper.java:
Esta classe fornece operações auxiliares, como a operação narrow(),necessária para fazer o cast de uma referência de objeto CORBA para o tipo boleto.
gerenciadorBoletoHolder.java 
Esta classe fornece operações para argumentos do tipo out e inout.
_gerenciadorBoletoStub.java
Esta classe é o stub do cliente, responsável por fornecer a funcionalidade básica do CORBA para o cliente.
gerenciadorBoletoPOA.java
Esta classe é o skeleton do servidor, responsável por fornecer a funcionalidade básica do CORBA para o servidor.
gerenciadorBoletoOperations.java
Esta classe contem os métodos da interface correio (enviar_boleto(boleto bol)). Todas as operações definidas na interface IDL são mapeadas para Java e colocadas no arquivo de operações
Após a compilação da IDL, basta implementar os códigos referentes aos métodos da interface “gerenciadorBoleto” definidos na IDL, e os códigos do Servidor(Servidor.java) e dos clientes(cliente1.java e cliente2.cpp) .
A classe Gerenciadorboletoimpl deve implementar todos os métodos da interface gerenciadorBoleto. Cada instância de gerenciadorBoleto é implementada pela GerenciadorBoletoImpl. O método enviar_boletopossui como parâmetro uma estrutura (definida na IDL e que é mapeada para uma classe emJava) boleto.
A implementação do servidor a utiliza o serviço de nome (Naming Service) para definir e encontrar os objetos. Abaixo encontra-se a implementação e os passos a sererm seguidos: 
Iniciar o ORB;
Criar uma instância da implementação do objeto CORBA correio;
Transformar o objeto em uma referência para objeto CORBA;
Obter a referência do serviço de nomes;
Registrar o novo objeto no servidor serviço de nomes, usando por exemplo onome “Servidor-GerenciadorBoleto”; 
Aguardar pelas invocações dos clientes ao objeto.
package br.com.uniceub.sd;
importorg.omg.CosNaming.*;
import tutorial.*;
publicclassServidor {
	staticpublicvoid main(String[] args) {
		try {
			// Inicia o ORB
			org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
			// Pega a referencia do POAManager e o inicializa
			org.omg.PortableServer.POArootpoa = org.omg.PortableServer.POAHelper
					.narrow(orb.resolve_initial_references("RootPOA"));
			rootpoa.the_POAManager().activate();
			// Cria o objeto
			GerenciadorBoletoImplobjCorreio = new GerenciadorBoletoImpl();
			// Transforma o objeto local emumareferencia CORBA
			org.omg.CORBA.Object ref = rootpoa.servant_to_reference(objCorreio);
			gerenciadorBoletogerenciadorBoletoRef = gerenciadorBoletoHelper.narrow(ref);
			// Obtem a referencia do servicodenomes
			org.omg.CORBA.ObjectnsRef = orb
					.resolve_initial_references("NameService");
			NamingContextExtncRef = NamingContextExtHelper.narrow(nsRef);
			// Faz a ligação (bind) do objetoaonome no serviçodenomes
			NameComponent[] name = newNameComponent[1];
			name[0] = newNameComponent("Servidor-GerenciadorBoleto", "");
			ncRef.rebind(name, gerenciadorBoletoRef);
			System.out.println("Servidor de Gerenciamento de Boleto iniciado com sucesso....\n\n");
			// Executa o ORB e ficaaguardandopelasinvocacoesdosclientes
			orb.run();
			
		}catch (Exception e) { // Casoocorraalgumerro
			System.err.println("ERROR: " + e);
		}
	}
}
O cliente1 também utiliza o Naming Service para acessar os objetos no servidor.Abaixo é mostrada uma possível implementação do cliente1, utilizando alinguagem de programação JAVA.
package br.com.uniceub.sd;
importorg.omg.CosNaming.*;
import tutorial.*;
public class Cliente1 {
	
	statictutorial.gerenciadorBoletoobjGerenciadorBoleto;
	
	static public void main(String[] args){
		try {
			
			// inicializa o ORB
			org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
			// Obtem a referencia do servico de nomes
			org.omg.CORBA.ObjectnsRef = orb
					.resolve_initial_references("NameService");
			NamingContextExtncRef = NamingContextExtHelper.narrow(nsRef);
			// Busca pelo nome no serviço de nomes
			NameComponent[] name = new NameComponent[1];
			name[0] = new NameComponent("Servidor-GerenciadorBoleto", "");
			org.omg.CORBA.ObjectobjRef = ncRef.resolve(name);
			// Converte o objeto para o tipo da interface GerenciadorBoleto
			objGerenciadorBoleto = gerenciadorBoletoHelper.narrow(objRef);			
			//Chama o menu interativo
			menu();
			
		}catch(Exception e) { //Em caso de algum erro
			System.err.println("\n\n Atencao - Nao foi possivel enviar a mensagem");
			System.err.println("System Exception: "+e);
		}
	}
	
	
	public static void menu(){
		java.io.BufferedReaderteclado = new java.io.BufferedReader(new
				java.io.InputStreamReader(System.in));
		String linha = "";
		try{
			while (!linha.equals("2")) {
				System.out.println("\n..:: GerenciadorBoleto eletronico ::..\n");
				System.out.println("1 - Enviar nova mensagem");
				System.out.println("2 - Sair\n");
				System.out.print("Entre com a opcao: ");
				try{
					linha = teclado.readLine();
				}catch(java.io.IOException e){
					System.err.println("ERRO DE IO: "+e);
				}
				if (linha.equals("1")){
					boletobol = new boleto();
					
					System.out.print("\nAluno: ");
					bol.aluno = teclado.readLine();
					System.out.print("Mes Referencia: ");
					bol.mesReferencia = teclado.readLine();
					System.out.print("Ano Referencia: ");
					bol.anoReferencia = teclado.readLine();
					System.out.print("Data Vencimento: ");
					bol.dataVencimento = teclado.readLine();
					System.out.print("Valor: ");
					bol.valor = teclado.readLine();
					// Invocacao do metodoenviar_bol;
							
			System.out.println(objGerenciadorBoleto.enviar_boleto(bol));
				}
			}
		}catch(Exception e){
			System.err.println("System Exception: "+e);
		}
	}
	
}
Agora é mostrada a classe, GerenciadorBoleto, que implementa todas as operações do servidor. 
package br.com.uniceub.sd;
importorg.omg.CosNaming.*;
import tutorial.*;
public classGerenciadorBoletoImplextendsgerenciadorBoletoPOA {
	// Constructor
	GerenciadorBoletoImpl() {
		System.out.println("Objeto gerenciador De Boleto criado com sucesso !");
	}
	@Override
	publicStringenviar_boleto(boleto bol) {
		
		System.out.println("\n...::: Boleto Enviado :::...\n");
		System.out.println("Aluno: " + bol.aluno);
		System.out.println("Refente a: " + bol.mesReferencia + "/" + bol.anoReferencia);
		System.out.println("Data Vencimento: " + bol.dataVencimento);
		System.out.println("Valor: " + bol.valor);
		System.out.println("...::: Fim do boleto :::...");
		
		return "Mensagem enviada com Sucesso";
	}
	@Override
	public boleto receber_boletor() {
		
		returnnull;
	}
}
A compilação de IDL para C++ resultou em insucesso após a utilização de diversos compiladores, tais como: 
MIDL:
Encontrado no Microsoft Windowns SDK – Software Development Kit –, on line na URL: http://www.microsoft.com/en-us/download/details.aspx?id=8279. Compilado conforme a documentação descrita na URL: http://msdn.microsoft.com/en-us/library/windows/desktop/aa367300(v=vs.85).aspx.
Resultado da compilação da IDL:
Para a compilação da IDL, utilizou-se o mesmo código descrito na Figura: “Figura 2 - Detalhamento da implementação do Skeleton”.
ORBacus: Impossibilidade de configuração do compilador.
 MICO - 2.3.13: Após tentativa de compilação do compilador, a partir do comando “nmake/ f makefile.win32”, gerou-se o seguinte erro:
Tela de erro da não compilação:
Encontrado on line na URL: http://sourceforge.net/projects/mico/files/latest/download
CONSIDERAÇÕES FINAIS
O desenvolvimento de um servidor utilizando a especificação CORBA, nas linguagens JAVA e C++, apresentou tanto facilidades quanto dificuldades. Como o framework CORBA possui transparência nas execuções de conceitos operacionais e protocolos de comunicação e hardware, o programador se abstém de preocupação com a transação dos mesmos. Em contrapartida, o suporte no desenvolvimento do CORBA é ineficaz.
O desenvolvimento do cliente em linguagem de programação JAVA possui tutoriais, exemplificações e conceitos bem definidos – pesquisados na internet –, que possibilita a implementação das bibliotecas e objetos, e compilar com êxito a IDL. Porém, para implementação no cliente em linguagem de programação C++, os artigos e tutoriais encontrados não foram suficientes para compilar corretamente a IDL. Por não possuir implementação padrão para o CORBA a execução e compilação de programas é dificultada.
Existem alguns pontos negativos descritos, porém, em associação de sistemas distribuídos como a aplicação de cliente-servidor, o CORBA possui notável escalabilidade, transparência e flexibilidade. Essa versatilidade potencializa a sua utilização em ambientes heterogêneos, como se observa nos sistemas atuais.
Referências bibliográficas
[1] ROCHA, José Antonio Meira da. Modelo de monografia e Trabalho de Conclusão de Curso (TCC). Documento digital do programa MS Word disponível em <http://meiradarocha.jor.br/news/tcc/files/2009/06/modelo_tcc-2011-11-23a.doc_.zip>. Acesso em: 11 de outubro de 2013.
[2] TANENBAUM, Andrew S.; VAN STEEN, Maarten. Distributed systems: principles and paradigms.New Jersey, USA: Prentice-Hall, 2002.
[3]COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas Distribuídos Conceitos e Projeto. 4ª Ed. Porto Alegre: Bookman, 2007. p.138-178
[4] Group, Object Management Inc. OMG We set the standard. [on line] Disponível na Internet URL: http://www.omg.org/spec. 11.nov.2013.
[5] ORBIX 3.3, IONA Technologies PLC. [on line] Disponível na Internet URL: http://documentation.progress.com/output/Iona/manuals/orbix/33/html/orbixnames33_pguide/Introduction.html. 11.nov.2013.
[6] IIOP: OMG’s Internet Inter-ORB Protocol A Brief Description. [on line] Disponível na Internet URL: http://www.omg.org/library/iiop4.html. 11.nov.2013
[7] http://www.microsoft.com/en-us/download/details.aspx?id=3138
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367300(v=vs.85).aspx.