Artigo distribuidos programação java com rmi e cobra
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Artigo distribuidos programação java com rmi e cobra

on

  • 1,912 views

 

Statistics

Views

Total Views
1,912
Views on SlideShare
1,782
Embed Views
130

Actions

Likes
0
Downloads
56
Comments
0

2 Embeds 130

http://www.novolarimoveis.adm.br 129
http://draft.blogger.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Artigo distribuidos programação java com rmi e cobra Document Transcript

  • 1. ArtigoDistribuí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 RMIDesenvolver um aplicativo distribuído usando RMI envolve as seguintes etapas:1. Definir uma interface remota2. Implementar a interface remota3. Desenvolver o servidor4. Desenvolver um cliente5. Gerar Stubs e Skeletons, inicie o registro RMI, servidor e clienteAgora, vamos examinar esses passos através do desenvolvimento de uma aplicação de transferência dearquivo.Exemplo: Aplicação de Transferência de ArquivosEsta aplicação permite que um cliente transferir (ou download) qualquer tipo de arquivo (texto ou binário) deuma máquina remota. O primeiro passo é definir uma interface remota que especifica as assinaturas dosmétodos a serem fornecidos pelo servidor e invocado pelos clientes.Definir uma interface remotaA interface remota para o aplicativo de download de arquivo é mostrado no código de exemplo 1. Ainterface FileInterface fornece um método downloadFile que leva uma String argumento (onome 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 remotaO próximo passo é implementar a interface FileInterface . A implementação de exemplo é mostradona Amostra de código 2. Observe que, além de implementar a FileInterface , o FileImpl classeestá estendendo a UnicastRemoteObject . Isto indica que o FileImpl classe é usada para criaruma única, não-replicado objecto, remoto que utiliza padrão RMI de transporte baseado em TCP para acomunicaçã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 servidorO 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á-lo2. 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 registroRMI está sendo executado o número da porta padrão, que é 1099. No entanto, se você executar o registroRMI em um número de porta diferente, deve ser especificado nessa declaração. Por exemplo, se o registroRMI é 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 namesma máquina. Se não forem, então simplesmente mudar o endereço no rebind método.Desenvolver um clienteO passo seguinte é o de desenvolver um cliente. O cliente invoca remotamente todos os métodosespecificados na interface remota ( FileInterface ). Para isso no entanto, o cliente deve primeiroobter 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. Nestaimplementação, o cliente aceita dois argumentos na linha de comando: o primeiro é o nome do arquivo a serbaixado 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 aplicativoPara executar o aplicativo, é preciso gerar stubs e esqueletos, compilar o servidor eo cliente, inicie o registroRMI e, finalmente, iniciar o servidor eo cliente.Para gerar stubs e esqueletos, utilize o rmic compilador:prompt> rmic FileImplIsso irá gerar dois arquivos: FileImpl_Stub.class e FileImpl_Skel.class . O stub é umproxy 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, noentanto, se o servidor eo cliente são desenvolvidos em duas máquinas diferentes, a fim de compilar o clienteprecisar 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 nonúmero da porta padrão, use o comando rmiregistry ou start rmiregistry no Windows. Parainiciar o registro RMI em um número de porta diferente, fornecer o número da porta como um argumentopara o registro RMI:prompt> rmiregistry portNumberUma vez que o registro RMI é executado, você pode iniciar o servidor FileServer . No entanto, desde aRMI gestor de segurança está sendo usado no aplicativo de servidor, você precisa de uma política deseguranç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çõesde 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 FileServerPara 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 ocomando:prompt> java FileClient fileName machineNameonde 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 é oarquivo baixado na máquina local.Para executar o cliente, mencionou que você precisa de uma cópia da interface e stub. Uma maneira maisadequada de fazer isso é usar RMI carregamento dinâmico de classe. A idéia é que você não precisa decópias da interface e do topo. Em vez disso, eles podem ser localizados em um diretório compartilhado parao servidor eo cliente, e sempre que um esboço ou um esqueleto é necessária, ela será baixadaautomaticamente 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/locationOfClassesFileClient fileName machineName . Para mais informações sobre este assunto,consulte Carregando dinâmicas de código usando RMI .CORBAO Common Object Request Broker Architecture (CORBA ou) é um padrão da indústria desenvolvido peloObject Management Group (OMG) para auxiliar na programação distribuída objetos. É importante notar queCORBA é simplesmente uma especificação. A implementação CORBA é conhecido como um ORB (ouObject Request Broker). Existem várias implementações de CORBA disponíveis no mercado, tais comoVisiBroker e Orbix, e outros. JavaIDL é outra aplicação que vem como um pacote de base com o JDK1.3 ousuperior.CORBA foi projetado para ser plataforma e linguagem independente. Portanto, objetos CORBA pode serexecutado em qualquer plataforma, localizada em qualquer ponto da rede, e podem ser escritos emqualquer 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ãoespecificadas em IDL. Enquanto IDL é semelhante ao C + +, é importante notar que IDL não é umalinguagem de programação. Para uma introdução detalhada ao CORBA, consulte Programação distribuídacom Java: Capítulo 11 (Visão geral de CORBA) .A Gênese de uma Aplicação CORBAHá um número de passos envolvidos no desenvolvimento de aplicações CORBA. Estes são:1. Definir uma interface em IDL2. Mapa da interface IDL para Java (feito automaticamente)3. Implementar a interface4. Desenvolver o servidor5. Desenvolver um cliente6. 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ênciabaseado em CORBA arquivo, que é semelhante à aplicação RMI foi desenvolvido no início desteartigo. Aqui estaremos usando o JavaIDL, que é um pacote essencial de JDK1.3 +.Definir a interfaceAo definir uma interface CORBA, pensar sobre o tipo de operações que o servidor irá suportar. No pedidode transferência de arquivo, o cliente irá chamar um método para baixar um arquivo. Amostra de código 5mostra a interface para FileInterface . Data é um novo tipo introduzidos utilizandoo typedef palavra-chave. Uma sequence em IDL é semelhante a uma matriz excepto que umasequência não tem um tamanho fixo. Um octet é uma quantidade de 8-bits que é equivalente ao tipoJava byte .
  • 6. Note que o downloadFile método recebe um parâmetro do tipo string que é declarada in . IDLdefine três de passagem de parâmetro modos: in (para a entrada do cliente para o servidor), out (para asaí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 vemcom 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 decliente, esqueletos de servidor, ou ambos. O -f<side> opção é usada para especificar o quegerar. Oside pode ser client , server , ou all para stubs cliente e esqueletos de servidor. Nesteexemplo, 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 ocomando:prompt> idlj -fserver FileInterface.idlEste comando gera vários arquivos, como esqueletos, suporte e classes auxiliares, e outros. Um arquivoimportante que é gerado é o _FileInterfaceImplBase , que vai ser uma subclasse da classe queimplementa a interface.Implementar a interfaceAgora, 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, aclasse FileServantestende a _FileInterfaceImplBase classe para especificar que esteservo é 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 servidorO próximo passo é desenvolver o servidor CORBA. O FileServer classe, mostrado no código deexemplo 7, implementa um servidor CORBA que faz o seguinte:1. Inicializa o ORB2. Cria um objeto FileServant
  • 7. 3. Registra o objeto no CORBA Naming Service (COS Naming)4. Imprime uma mensagem de status5. Aguarda solicitações de cliente recebidasAmostra 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 COSNaming especificado pelo OMG e implementado por Java IDL para fazer o registro. Ele começa por obteruma referência para a raiz do serviço de nomes. Isso retorna um objeto CORBA genérico. Para usá-lo comoum NamingContext objecto, ele deve ser reduzida (por outras palavras, fundido) para o seu tipopró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 pararegistrar um serviço CORBA com o serviço de identificação usando o rebind método.Desenvolver um clienteO passo seguinte é o de desenvolver um cliente. Uma implementação é mostrado na exemplo de código8. Uma vez que uma referência para o serviço de identificação foi obtido, pode ser utilizado para aceder aoserviço de identificação e encontrar outros serviços (por exemplo, o FileTransfer serviço). Quandoo 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 aplicativoO 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 25002. 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 25003. 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.idl4. 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 denomes 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 4500Alternativamente, essas opções podem ser especificadas no nível do código usando aspropriedades. 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 doserviç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);ExercerNo pedido de transferência de arquivo, o cliente (em ambos os casos, RMI e CORBA) precisa saber o nomedo arquivo a ser baixado com antecedência. Não há métodos são fornecidos para listar os arquivosdisponíveis no servidor. Como um exercício, você pode querer melhorar a aplicação, adicionando um outrométodo que lista os arquivos disponíveis no servidor. Além disso, em vez de usar um cliente de linha decomando você pode querer desenvolver um cliente baseado em GUI. Quando o cliente é iniciado, elechama um método no servidor para obter uma lista de arquivos, em seguida aparece um menu contendo osarquivos disponíveis onde o usuário seria capaz de selecionar um ou mais arquivos a serem baixados, comomostrado na Figura 1. Figura 1: GUI baseada em cliente File TransferCORBA versus RMI
  • 10. Code-sábio, é claro que RMI é mais simples de trabalhar com uma vez que o desenvolvedor Java nãoprecisa estar familiarizado com a Interface Definition Language (IDL). Em geral, contudo, difere de CORBARMI 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ãoDesenvolvimento de objetos distribuídos aplicações baseadas pode ser feito em Java utilizando RMI ouJavaIDL (uma implementação de CORBA). O uso de ambas as tecnologias é semelhante uma vez que oprimeiro passo consiste em definir uma interface para o objecto. Ao contrário de RMI, no entanto, ondeinterfaces são definidas em Java, as interfaces de CORBA são definidos na linguagem de definição deinterface (IDL). Isso, no entanto, acrescenta outra camada de complexidade, onde o desenvolvedor precisaestar 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 eseus requisitos. Espero que este artigo lhe forneceu informações suficientes para começar a desenvolverdistribuídas objeto e aplicações de base de orientação o suficiente para ajudá-lo a selecionar ummecanismo 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