1. Artigo
Distribuído Programação Java com RMI e CORBA
Versão para Impressão
Índice de artigos
Qusay H. Mahmoud
Janeiro 2002
O Java Remote Method Invocation mecanismo (RMI) e Common Object Request Broker Architecture
(CORBA) são os dois mais importantes e amplamente utilizados sistemas de objetos distribuídos. Cada
sistema tem suas próprias características e limitações. Ambos estão sendo usados na indústria para várias
aplicações que vão desde e-commerce aos cuidados de saúde. Seleção de qual desses dois mecanismos
de distribuição de usar para um projeto é uma tarefa difícil. Este artigo apresenta uma visão geral da RMI e
CORBA, e mais importante ainda, mostra como desenvolver uma aplicação útil para download de arquivos
de hosts remotos. Em seguida:
 Apresenta uma breve descrição dos sistemas de objetos distribuídos
 Fornece uma visão geral de RMI e CORBA
 Dá-lhe um sabor do esforço envolvido no desenvolvimento de aplicações em RMI e CORBA
 Mostra como transferir arquivos de máquinas remotas usando RMI e CORBA
 Fornece uma breve comparação de RMI e CORBA
O modelo cliente / servidor
O modelo cliente / servidor é uma forma de computação distribuída em que um programa (o cliente) se
comunica com outro programa (o servidor) com o objetivo de trocar informações. Neste modelo, o cliente eo
servidor geralmente falam a mesma língua - um protocolo que o cliente eo servidor de entender - para que
eles sejam capazes de se comunicar.
Enquanto o modelo de cliente / servidor pode ser implementada de várias maneiras, ele é tipicamente feito
usando baixo nível sockets. Usando sockets para desenvolver sistemas cliente / servidor significa que
devemos projetar um protocolo, que é um conjunto de comandos acordadas pelo cliente e servidor através
do qual eles serão capazes de se comunicar. Como exemplo, considere o protocolo HTTP que fornece um
método chamado GET , que deve ser implementada por todos os servidores web e usado por clientes web
(browsers), a fim de recuperar os documentos.
O Modelo de Objetos Distribuído
Um sistema baseado em objeto distribuído é uma coleção de objetos que isola os solicitantes de serviços
(clientes) de os prestadores de serviços (servidores) por uma interface bem definida de
encapsulamento. Em outras palavras, os clientes são isoladas a partir da implementação de serviços de
dados como representações e de código executável. Esta é uma das principais diferenças que distinguem o
modelo baseado em objetos distribuídos a partir do modelo cliente / servidor puro.
No modelo baseado em objetos distribuídos, um cliente envia uma mensagem a um objeto, que por sua vez
interpreta a mensagem para decidir que serviço a executar. Este serviço, ou método, a seleção poderia ser
realizada por qualquer objeto ou um corretor. O Java Remote Method Invocation (RMI) e Common Object
Request Broker Architecture (CORBA) são exemplos deste modelo.
RMI
RMI é um sistema de objetos distribuídos que lhe permite desenvolver facilmente aplicações distribuídas em
Java. Desenvolvimento de aplicações distribuídas em RMI é mais simples do que desenvolver com sockets,
pois não há necessidade de criar um protocolo, que é uma tarefa propensa a erros. Em RMI, o
desenvolvedor tem a ilusão de chamar um método local de um arquivo de classe local, quando na verdade
os argumentos são enviados para o destino remoto e interpretados, e os resultados são enviados de volta
para os chamadores.

2. A Gênese de uma aplicação RMI
Desenvolver um aplicativo distribuído usando RMI envolve as seguintes etapas:
1. Definir uma interface remota
2. Implementar a interface remota
3. Desenvolver o servidor
4. Desenvolver um cliente
5. Gerar Stubs e Skeletons, inicie o registro RMI, servidor e cliente
Agora, vamos examinar esses passos através do desenvolvimento de uma aplicação de transferência de
arquivo.
Exemplo: Aplicação de Transferência de Arquivos
Esta aplicação permite que um cliente transferir (ou download) qualquer tipo de arquivo (texto ou binário) de
uma máquina remota. O primeiro passo é definir uma interface remota que especifica as assinaturas dos
métodos a serem fornecidos pelo servidor e invocado pelos clientes.
Definir uma interface remota
A interface remota para o aplicativo de download de arquivo é mostrado no código de exemplo 1. A
interface FileInterface fornece um método downloadFile que leva uma String argumento (o
nome do arquivo) e retorna os dados do arquivo como um array de bytes.
Amostra de código 1: FileInterface.java
importar java.rmi.Remote;
java.rmi.RemoteException de importação;
public interface FileInterface estende remoto {
public byte [] DownloadFile (String fileName) throws
RemoteException;
}
Observe as seguintes características sobre o FileInterface :
 Deve ser declarada public , para que os clientes para ser capaz de carregar objetos remotos que
implementam a interface remota.
 Deve estender a Remote interface, para cumprir a exigência para fazer o objeto a um controle remoto.
 Cada método da interface deve lançar um java.rmi.RemoteException .
Implementar a interface remota
O próximo passo é implementar a interface FileInterface . A implementação de exemplo é mostrado
na Amostra de código 2. Observe que, além de implementar a FileInterface , o FileImpl classe
está estendendo a UnicastRemoteObject . Isto indica que o FileImpl classe é usada para criar
uma única, não-replicado objecto, remoto que utiliza padrão RMI de transporte baseado em TCP para a
comunicação.
Amostra de código 2: FileImpl.java
import java.io. *;
importar java.rmi *.;
importação classe java.rmi.server.UnicastRemoteObject;
public class FileImpl estende UnicastRemoteObject
implementa FileInterface {
private String nome;
público FileImpl (String s) throws RemoteException {
super ();
name = s;

3. }
public byte [] DownloadFile (String fileName) {
try {
Arquivo file = new File (fileName);
buffer de byte [] = new byte [file.length (int) ()];
BufferedInputStream entrada = new
BufferedInputStream (new FileInputStream (fileName));
input.read (buffer, 0, buffer.Length);
input.close ();
retorno (buffer);
} Catch (Exception e) {
System.out.println ("FileImpl:" + e.getMessage ());
e.printStackTrace ();
return (null);
}
}
}
Desenvolver o servidor
O terceiro passo é o de desenvolver um servidor. Há três coisas que o servidor precisa fazer:
1. Criar uma instância do RMISecurityManager e instalá-lo
2. Criar uma instância do objeto remoto ( FileImpl neste caso)
3. Registre o objeto criado com o registro RMI. A implementação de exemplo é mostrado na 3 Amostra de
código.
Amostra de código 3: FileServer.java
import java.io. *;
importar java.rmi *.;
FileServer public class {
public static void main (String argv []) {
if (System.getSecurityManager () == null) {
System.setSecurityManager (novo RMISecurityManager ());
}
try {
FileInterface fi = new FileImpl ("FileServer");
Naming.rebind ("/ 127.0.0.1/FileServer /", fi);
} Catch (Exception e) {
System.out.println ("FileServer:" + e.getMessage ());
e.printStackTrace ();
}
}
}
A declaração Naming.rebind("//127.0.0.1/FileServer", fi) assume que o registro
RMI está sendo executado o número da porta padrão, que é 1099. No entanto, se você executar o registro
RMI em um número de porta diferente, deve ser especificado nessa declaração. Por exemplo, se o registro
RMI é executado na porta 4500, então a declaração torna-se:
Naming.rebind("//127.0.0.1:4500/FileServer", fi)
Além disso, é importante notar aqui que nós assumimos o RMI Registry eo servidor estará rodando na
mesma máquina. Se não forem, então simplesmente mudar o endereço no rebind método.
Desenvolver um cliente
O passo seguinte é o de desenvolver um cliente. O cliente invoca remotamente todos os métodos
especificados na interface remota ( FileInterface ). Para isso no entanto, o cliente deve primeiro
obter uma referência para o objeto remoto a partir do registro RMI. Uma vez que uma referência é obtido,
o downloadFile método é invocado. A aplicação cliente é apresentado em 4 Amostra de código. Nesta
implementação, o cliente aceita dois argumentos na linha de comando: o primeiro é o nome do arquivo a ser
baixado eo segundo é o endereço da máquina do qual o arquivo deve ser baixado, que é a máquina que

4. está executando o servidor de arquivos.
Amostra de código 4: FileClient.java
import java.io. *;
importar java.rmi *.;
public class {FileClient
public static void main (String argv []) {
if (argv.length! = 2) {
System.out.println ("Uso: java fileName FileClient machineName");
System.exit (0);
}
try {
String nome = "/ /" + argv [1] + "FileServer /";
FileInterface fi = Naming.lookup (FileInterface) (nome);
byte [] = filedata fi.downloadFile (argv [0]);
Arquivo file = new File (argv [0]);
Saída BufferedOutputStream = new
BufferedOutputStream (new FileOutputStream (file.getName ()));
output.write (filedata, 0, filedata.length);
output.flush ();
output.close ();
} Catch (Exception e) {
System.err.println ("exceção FileServer:" + e.getMessage ());
e.printStackTrace ();
}
}
}
Executando o aplicativo
Para executar o aplicativo, é preciso gerar stubs e esqueletos, compilar o servidor eo cliente, inicie o registro
RMI e, finalmente, iniciar o servidor eo cliente.
Para gerar stubs e esqueletos, utilize o rmic compilador:
prompt> rmic FileImpl
Isso irá gerar dois arquivos: FileImpl_Stub.class e FileImpl_Skel.class . O stub é um
proxy do cliente e o esqueleto é um esqueleto do servidor.
O próximo passo é compilar o servidor eo cliente. Use o javac compilador para fazer isso. Note, no
entanto, se o servidor eo cliente são desenvolvidos em duas máquinas diferentes, a fim de compilar o cliente
precisar de uma cópia da interface ( FileInterface ).
Finalmente, é hora de começar o registro RMI e executar o servidor eo cliente. Para iniciar o registro RMI no
número da porta padrão, use o comando rmiregistry ou start rmiregistry no Windows. Para
iniciar o registro RMI em um número de porta diferente, fornecer o número da porta como um argumento
para o registro RMI:
prompt> rmiregistry portNumber
Uma vez que o registro RMI é executado, você pode iniciar o servidor FileServer . No entanto, desde a
RMI gestor de segurança está sendo usado no aplicativo de servidor, você precisa de uma política de
segurança para ir com ele. Aqui está uma política de segurança da amostra:
grant {
java.security.AllPermission permissão "", "";
};
Nota: este é apenas um exemplo de política. Ele permite que ninguém a fazer nada. Para suas aplicações
de missão crítica, você precisa especificar as políticas de segurança mais restrição.
Agora, para iniciar o servidor precisar de uma cópia de todas as classes (incluindo stubs e esqueletos),
exceto a classe cliente ( FileClient.class ). Para iniciar o servidor use o seguinte comando,
assumindo que a política de segurança está em um arquivo chamado Policy.txt:

5. prompt> java -Djava.security.policy=policy.txt FileServer
Para iniciar o cliente em uma máquina diferente, você precisa de uma cópia da interface remota
( FileInterface.class ) e stub ( FileImpl_Stub.class ). Para iniciar o cliente use o
comando:
prompt> java FileClient fileName machineName
onde fileName é o arquivo a ser baixado e machineName é a máquina onde o arquivo está localizado
(a mesma máquina roda o servidor de arquivos). Se tudo der certo, em seguida, o cliente existe e é o
arquivo baixado na máquina local.
Para executar o cliente, mencionou que você precisa de uma cópia da interface e stub. Uma maneira mais
adequada de fazer isso é usar RMI carregamento dinâmico de classe. A idéia é que você não precisa de
cópias da interface e do topo. Em vez disso, eles podem ser localizados em um diretório compartilhado para
o servidor eo cliente, e sempre que um esboço ou um esqueleto é necessária, ela será baixada
automaticamente pelo carregador de classe RMI. Para fazer isso você executar o cliente, por exemplo,
usando o seguinte comando: java -
Djava.rmi.server.codebase=http://hostname/locationOfClasses
FileClient fileName machineName . Para mais informações sobre este assunto,
consulte Carregando dinâmicas de código usando RMI .
CORBA
O Common Object Request Broker Architecture (CORBA ou) é um padrão da indústria desenvolvido pelo
Object Management Group (OMG) para auxiliar na programação distribuída objetos. É importante notar que
CORBA é simplesmente uma especificação. A implementação CORBA é conhecido como um ORB (ou
Object Request Broker). Existem várias implementações de CORBA disponíveis no mercado, tais como
VisiBroker e Orbix, e outros. JavaIDL é outra aplicação que vem como um pacote de base com o JDK1.3 ou
superior.
CORBA foi projetado para ser plataforma e linguagem independente. Portanto, objetos CORBA pode ser
executado em qualquer plataforma, localizada em qualquer ponto da rede, e podem ser escritos em
qualquer língua que tem Language Interface Definition Language (IDL) mapeamentos.
Similar a RMI, objetos CORBA são especificadas com interfaces. As interfaces em CORBA, no entanto, são
especificadas em IDL. Enquanto IDL é semelhante ao C + +, é importante notar que IDL não é uma
linguagem de programação. Para uma introdução detalhada ao CORBA, consulte Programação distribuída
com Java: Capítulo 11 (Visão geral de CORBA) .
A Gênese de uma Aplicação CORBA
Há um número de passos envolvidos no desenvolvimento de aplicações CORBA. Estes são:
1. Definir uma interface em IDL
2. Mapa da interface IDL para Java (feito automaticamente)
3. Implementar a interface
4. Desenvolver o servidor
5. Desenvolver um cliente
6. Executar o serviço de nomes, o servidor eo cliente.
Vamos agora explicar cada passo a passos através do desenvolvimento de uma aplicação de transferência
baseado em CORBA arquivo, que é semelhante à aplicação RMI foi desenvolvido no início deste
artigo. Aqui estaremos usando o JavaIDL, que é um pacote essencial de JDK1.3 +.
Definir a interface
Ao definir uma interface CORBA, pensar sobre o tipo de operações que o servidor irá suportar. No pedido
de transferência de arquivo, o cliente irá chamar um método para baixar um arquivo. Amostra de código 5
mostra a interface para FileInterface . Data é um novo tipo introduzidos utilizando
o typedef palavra-chave. Uma sequence em IDL é semelhante a uma matriz excepto que uma
sequência não tem um tamanho fixo. Um octet é uma quantidade de 8-bits que é equivalente ao tipo
Java byte .

6. Note que o downloadFile método recebe um parâmetro do tipo string que é declarada in . IDL
define três de passagem de parâmetro modos: in (para a entrada do cliente para o servidor), out (para a
saída do servidor para o cliente), e inout (usado para entrada e saída).
Amostra de código 5: FileInterface.idl
interface de FileInterface {
Dados <octet> typedef seqüência;
Dados DownloadFile (em string fileName);
};
Uma vez que você terminar de definir a interface IDL, você está pronto para compilá-lo. O + JDK1.3 vem
com o idlj compilador, que é usado para definições de mapa em declarações IDL Java e declarações.
O idlj compilador aceita opções que permitem que você especifique se você deseja gerar stubs de
cliente, esqueletos de servidor, ou ambos. O -f<side> opção é usada para especificar o que
gerar. Oside pode ser client , server , ou all para stubs cliente e esqueletos de servidor. Neste
exemplo, uma vez que o aplicativo será executado em duas máquinas separadas, o -fserver opção é
utilizado no lado do servidor, e -fclient opção é usada no lado do cliente.
Agora, vamos compilar o FileInterface.idl e gerar esqueletos do lado do servidor. Usando o
comando:
prompt> idlj -fserver FileInterface.idl
Este comando gera vários arquivos, como esqueletos, suporte e classes auxiliares, e outros. Um arquivo
importante que é gerado é o _FileInterfaceImplBase , que vai ser uma subclasse da classe que
implementa a interface.
Implementar a interface
Agora, nós fornecemos uma implementação para o downloadFile método. Esta implementação é
conhecido como um servo, e como você pode ver a partir de Amostra de código 6, a
classe FileServantestende a _FileInterfaceImplBase classe para especificar que este
servo é um objeto CORBA.
Amostra de código 6: FileServant.java
import java.io. *;
public class extends FileServant _FileInterfaceImplBase {
public byte [] DownloadFile (String fileName) {
Arquivo file = new File (fileName);
buffer de byte [] = new byte [file.length (int) ()];
try {
BufferedInputStream entrada = new
BufferedInputStream (new FileInputStream (fileName));
input.read (buffer, 0, buffer.Length);
input.close ();
} Catch (Exception e) {
System.out.println ("Erro FileServant:" + e.getMessage ());
e.printStackTrace ();
}
retorno (buffer);
}
}
Desenvolver o servidor
O próximo passo é desenvolver o servidor CORBA. O FileServer classe, mostrado no código de
exemplo 7, implementa um servidor CORBA que faz o seguinte:
1. Inicializa o ORB
2. Cria um objeto FileServant

7. 3. Registra o objeto no CORBA Naming Service (COS Naming)
4. Imprime uma mensagem de status
5. Aguarda solicitações de cliente recebidas
Amostra de código 7: FileServer.java
import java.io. *;
importar org.omg.CosNaming *.;
importar org.omg.CosNaming.NamingContextPackage *.;
importar org.omg.CORBA *.;
FileServer public class {
public static void main (String args []) {
try {
/ / Criar e inicializar o ORB
ORB orb = ORB.init (args, null);
/ / Cria o servo e registrá-lo com o ORB
Fileref FileServant FileServant = new ();
orb.connect (fileref);
/ / Obter o contexto de nomeação de raiz
org.omg.CORBA.Object objRef =
orb.resolve_initial_references ("NameService");
NamingContext ncRef = NamingContextHelper.narrow (objRef);
/ / Vincular o objeto de referência na nomeação
NameComponent nc = new NameComponent ("FileTransfer", "");
NameComponent caminho [] = {nc};
ncRef.rebind (caminho, fileref);
System.out.println ("Servidor começou ....");
/ / Espera invocações dos clientes
sync java.lang.Object java.lang.Object = new ();
sincronizado (sync) {
sync.wait ();
}
} Catch (Exception e) {
System.out.println ("ERRO:" + e.getMessage ());
e.printStackTrace (System.out);
}
}
}
Uma vez que o FileServer tem um ORB, ele pode registrar o serviço CORBA. Ele usa o serviço COS
Naming especificado pelo OMG e implementado por Java IDL para fazer o registro. Ele começa por obter
uma referência para a raiz do serviço de nomes. Isso retorna um objeto CORBA genérico. Para usá-lo como
um NamingContext objecto, ele deve ser reduzida (por outras palavras, fundido) para o seu tipo
próprio, e isto é feito utilizando a instrução:
NamingContext ncRef = NamingContextHelper.narrow(objRef);
O ncRef objeto é agora um org.omg.CosNaming.NamingContext . Você pode usá-lo para
registrar um serviço CORBA com o serviço de identificação usando o rebind método.
Desenvolver um cliente
O passo seguinte é o de desenvolver um cliente. Uma implementação é mostrado na exemplo de código
8. Uma vez que uma referência para o serviço de identificação foi obtido, pode ser utilizado para aceder ao
serviço de identificação e encontrar outros serviços (por exemplo, o FileTransfer serviço). Quando
o FileTransfer serviço for encontrado, o downloadFile método é chamado.
Amostra de código 8: FileClient
import java.io. *;
* import java.util.;
importar org.omg.CosNaming *.;
importar org.omg.CORBA *.;
public class {FileClient
public static void main (String argv []) {
try {

8. / / Criar e inicializar o ORB
ORB orb = ORB.init (argv, null);
/ / Obter o contexto de nomeação de raiz
org.omg.CORBA.Object objRef =
orb.resolve_initial_references ("NameService");
NamingContext ncRef = NamingContextHelper.narrow (objRef);
NameComponent nc = new NameComponent ("FileTransfer", "");
/ / Resolve o objeto de referência na nomeação
NameComponent caminho [] = {nc};
FileInterfaceOperations fileref =
FileInterfaceHelper.narrow (ncRef.resolve (caminho));
if (argv.length <1) {
System.out.println ("Uso: java FileClient filename");
}
/ / Salvar o arquivo
Arquivo file = new File (argv [0]);
dados de byte [] = fileRef.downloadFile (argv [0]);
Saída BufferedOutputStream = new
BufferedOutputStream (new FileOutputStream (argv [0]));
output.write (dados, 0, data.length);
output.flush ();
output.close ();
} Catch (Exception e) {
System.out.println ("Erro FileClient:" + e.getMessage ());
e.printStackTrace ();
}
}
}
Executando o aplicativo
O passo final é executar o aplicativo. Existem várias sub-etapas envolvidas:
1. A execução do serviço de nomes CORBA o. Isto pode ser feito usando o comando tnameserv . Por
padrão, ele é executado na porta 900. Se você não pode executar o serviço de nomes nesta porta,
então você pode iniciá-lo em outra porta. Para iniciá-lo na porta 2500, por exemplo, use o seguinte
comando:
prompt> tnameserv -ORBinitialPort 2500
2. Iniciar o servidor. Isto pode ser feito da seguinte forma, supondo que o serviço de nomes está sendo
executado no número de porta padrão:
prompt> java FileServer
Se o serviço de nomes está sendo executado em um número de porta diferente, digamos 2500, então
você precisa especificar a porta usando o ORBInitialPort opção da seguinte forma:
prompt> java FileServer -ORBInitialPort 2500
3. Gerar Stubs para o cliente. Antes de executar o cliente, precisamos gerar stubs para o cliente. Para
isso, obter uma cópia do FileInterface.idl arquivo e compilá-lo usando o compilador idlj
especificando que você deseja gerar stubs do lado do cliente, como segue:
prompt> idlj -fclient FileInterface.idl
4. Execute o cliente. Agora você pode executar o cliente usando o seguinte comando, assumindo que o
serviço de nomes é executado na porta 2500.
prompt> java FileClient hello.txt -ORBInitialPort 2500
Onde hello.txt é o arquivo que deseja baixar a partir do servidor.

9. Nota: se o serviço de nomes está sendo executado em um host diferente, então use o -
ORBInitialHost opção para especificar onde ele está sendo executado. Por exemplo, se o serviço de
nomes está sendo executado na porta de número 4500 em um host com o nome de gosling , então você
começa o cliente como se segue:
prompt> java FileClient hello.txt -ORBInitialHost gosling -
ORBInitialPort 4500
Alternativamente, essas opções podem ser especificadas no nível do código usando as
propriedades. Então, ao invés de inicializar o ORB como:
ORB orb = ORB.init(argv, null);
Ele pode ser inicializado especificando que a máquina do servidor CORBA (chamado Gosling) e número do
serviço de identificação do porta (a ser 2500) como se segue:
Properties props = new Properties ();
props.put ("org.omg.CORBA.ORBInitialHost", "gosling");
props.put ("orb.omg.CORBA.ORBInitialPort", "2500");
ORB orb = ORB.init (args, props);
Exercer
No pedido de transferência de arquivo, o cliente (em ambos os casos, RMI e CORBA) precisa saber o nome
do arquivo a ser baixado com antecedência. Não há métodos são fornecidos para listar os arquivos
disponíveis no servidor. Como um exercício, você pode querer melhorar a aplicação, adicionando um outro
método que lista os arquivos disponíveis no servidor. Além disso, em vez de usar um cliente de linha de
comando você pode querer desenvolver um cliente baseado em GUI. Quando o cliente é iniciado, ele
chama um método no servidor para obter uma lista de arquivos, em seguida aparece um menu contendo os
arquivos disponíveis onde o usuário seria capaz de selecionar um ou mais arquivos a serem baixados, como
mostrado na Figura 1.
Figura 1: GUI baseada em cliente File Transfer
CORBA versus RMI

10. Code-sábio, é claro que RMI é mais simples de trabalhar com uma vez que o desenvolvedor Java não
precisa estar familiarizado com a Interface Definition Language (IDL). Em geral, contudo, difere de CORBA
RMI nas seguintes áreas:
 Interfaces de CORBA são definidos em IDL e interfaces de RMI são definidos em Java. RMI-IIOP
permite que você escreva todas as interfaces em Java (ver RMI-IIOP ).
 CORBA suporta in e out parâmetros, enquanto RMI não faz desde que os objetos locais são
passados por cópia e objetos remotos são passados por referência.
 CORBA foi projetado com independência de linguagem em mente. Isso significa que alguns dos objetos
podem ser escritos em Java, por exemplo, e outros objetos podem ser escritos em C + + e ainda que
todos eles podem interoperar. Portanto, CORBA é um mecanismo ideal para colmatar ilhas entre
diferentes linguagens de programação. Por outro lado, RMI foi projetado para uma única língua em que
todos os objetos são escritos em Java. Note no entanto, com RMI-IIOP é possível alcançar a
interoperabilidade.
 Objetos CORBA não são lixo coletado. Como mencionamos, CORBA é independente de linguagem e
algumas linguagens (C + +, por exemplo) não suportam a coleta de lixo. Isto pode ser considerado uma
desvantagem já que uma vez um objeto CORBA é criado, ele continua a existir até que você se livrar
dele, e decidir quando se livrar de um objeto não é uma tarefa trivial. Por outro lado, os objetos RMI são
lixo coletado automaticamente.
Conclusão
Desenvolvimento de objetos distribuídos aplicações baseadas pode ser feito em Java utilizando RMI ou
JavaIDL (uma implementação de CORBA). O uso de ambas as tecnologias é semelhante uma vez que o
primeiro passo consiste em definir uma interface para o objecto. Ao contrário de RMI, no entanto, onde
interfaces são definidas em Java, as interfaces de CORBA são definidos na linguagem de definição de
interface (IDL). Isso, no entanto, acrescenta outra camada de complexidade, onde o desenvolvedor precisa
estar familiarizado com IDL, e igualmente importante, o mapeamento para Java.
Fazer uma seleção entre estes dois mecanismos de distribuição realmente depende do projeto na mão e
seus requisitos. Espero que este artigo lhe forneceu informações suficientes para começar a desenvolver
distribuídas objeto e aplicações de base de orientação o suficiente para ajudá-lo a selecionar um
mecanismo de distribuição.
Para mais informações
- RMI
- Especificação CORBA (OMG)
- JavaIDL
- Programação Distribuída com Java livro (Capítulo 11: Visão geral de CORBA)
- Servidor CORBA e cliente Servlet
- RMI-IIOP