Sistemas Distribuidos RMI

Olá pessoal do bem,

este post é um para colocar um pouco sobre um framework de desenvolvimento de sistemas distribuidos.

Estou estudando a arquitetura RMI (Remote Method Invocation), assim vou colocar aqui compartilhando o que eu conseguir absorver de conhecimento nesses estudos.

A seguir está o ‘white paper’ do trabalho de RMI.

Sistemas Distribuídos

Framework de desenvolvimento

Java RMI

Autor: Paulo Tiago Castanho Mariano

  1. Introdução

1.1 Conhecimento

Execuções em sistemas distribuídos requerem que sejam em hospedeiros distintos e possivelmente em diferentes espaços de endereçamento e ser possível a comunicação. Para mecanismos básicos de comunicação, a linguagem de programação Java possui suporte para sockets, que são maleáveis e atendem as necessidades genéricas. Contudo sockets exige que as aplicações devam ter os mesmos protocolos de aplicação e esse procedimento não é intuitivo e pode ser propenso a erros.

Uma alternativa para desenvolvimento sockets é RPC (Remote Procedure Call – tradução Chamada de Procedimento Remoto), que abstrai a interface de comunicação para nível de chamada de procedimento, o programador tem a ilusão de chamar um procedimento local, quando na verdade os argumentos da chamada são empacotados e enviados para chamada alvo. O sistema RCP codifica os valores e retorna os dados usando uma representação externa como XDR.

RPC, entretanto, não traduz bem como se comporta um sistema distribuído, onde a comunicação entre nível de programa objeto é necessário residir em diferentes espaços de endereçamento. Da forma a igualar a invocação de objetos remotos há necessidade de invocação de métodos remotos (RMI). Nesses sistemas, um objeto substituto local (stub) gerencia a invocação do objeto remoto.

O sistema de invocação de método remoto foi especificamente projetado para operar em ambiente de aplicativo Java, assume ambiente homogêneo de maquinas virtuais Java (JVM), por conseqüência ter maior aproveitamento do modelo de objetos Java.

            1.2 Objetivos

Os objetivos principais em dar suporte a objetos distribuídos Java são:

  • Suporte contínuo a invocação remota de objetos em maquinas virtuais distintas.
  • Prever chamadas de servidores para aplicativos (applets)
  • Integrar o modelo de sistemas distribuídos de modo natural à semântica da linguagem de programação Java
  • Escrever aplicações distribuídas de forma simples o mais confiável possível
  • Preservar a confiança do tipo de segurança prestado por meio da plataforma Java em ambiente de execução
  • Semântica de referencia a objetos remotos, como por exemplo, execução ao vivo (sem persistência), com persistência, fácil ativação.
  • Manter o ambiente seguro da plataforma Java fornecida pelos gestores de segurança e de class loaders.

 

  1. Modelo de Objetos Distribuídos.

2.1 Aplicações de Objetos Distribuídos

Aplicações RMI são de modo geral compostas por dois objetos distintos: Servidor e Cliente. Uma aplicação servidor típica cria um numero de objetos remotos, faz referencias acessíveis a esses objetos, e espera clientes solicitarem a invocação desses objetos através de métodos. Uma aplicação cliente típica busca referencias remotas em um ou mais objetos remotos no servidor e invoca os métodos dos mesmos.RMI prove mecanismos que cliente e servidor troquem informações mutuamente, esse pedido é referido como uma aplicação de objetos distribuídos.

Aplicação de objetos distribuídos precisa:

— Localizar objetos distribuídos;

            Aplicações podem usar um de dois métodos para obter referencias a objetos remotos. Uma aplicação pode registrar o objeto remoto com RMI simple naming facility (instalação simples nomeação), o rmiregistry, ou a aplicação pode passar e retornar referencias ao objeto remoto como parte de sua execução normal.

 — Comunicar com objetos remotos;

            Detalhes da comunicação de objetos remotos são tratados por RMI. O programador vê a comunicação remota como uma invocação de método padrão.

— Carregar código-fonte de classes passadas como parâmetro ou retornar valores

            Por causa de RMI permitir uma chamada para passar objetos para objetos remotos, RMI fornece os mecanismos necessários para carregar o código de objetos, bem como transmitir os seus dados.

A ilustração a seguir demonstra uma aplicação distribuída RMI usando o registry para obter referências dos objetos remotos. O servidor chama o registry para associar um nome com o objeto remoto. O Cliente localiza o objeto remoto pelo nome no servidor de registro e então invoca o método. A ilustração também mostra que o sistema RMI usa um servidor web existente para carregar código de classes escritas em linguagem Java, do servidor para o cliente, e do cliente para o servidor, para objetos quando necessita. RMI pode carregar código de classes usando qualquer protocolo URL (ex. HTTP, FTP, file, etc.) sendo suportada plataforma Java.

            2.2 Definições dos Termos

Na plataforma Java em modelo de objetos distribuídos, um objeto remoto é aquele cujos métodos podem ser invocados a partir de outra máquina virtual Java, possivelmente em um host diferente. Um objeto deste tipo é descrito por uma ou mais interfaces remotas, que são interfaces escritas em linguagem de programação Java que declare os métodos do objeto remoto.

Remote Method Invocation (RMI) é a ação de invocar métodos remotos de objetos remotos ou de interfaces remotas. Mais importante ainda, uma invocação de método em um objeto remoto tem a mesma sintaxe que uma invocação de método em um objeto local.

            2.3 Visão Geral das classes e interfaces RMI

As interfaces e as classes são responsáveis por especificar o comportamento remoto do sistema RMI estão definidos na hierarquia do pacote java.rmi. A figura a seguir mostra o relacionamento entre varias dessas classes e interfaces:

            2.3.1 A interface java.rmi.Remote

Em RMI, a interface Remote é que declara um conjunto de métodos que podem ser invocados a partir de uma maquina virtual Java.Os requerimentos para satisfazer a interface Remote são:

— a interface Remote deve pelo menos estender, direta ou indiretamente, a interface java.rmi.Remote

— cada método declarado na interface remota ou nas super-classes devem satisfazer os requisitos de uma declaração de método remoto como a seguir:

            — a declaração de um método remoto deve incluir a exceção java.rmi.RemoteException (ou uma de suas super-classes como java.io.Exception ou java.lang.Exception) na sua cláusula ‘throws’, alem de todas as exceções especificas dos objetos(note que a exceção especifica não deve extender java.rmi.RemoteException).

            — na declaração de método remoto, um objeto remoto declarado em um parâmetro ou como valor de retorno (quer declarado diretamente como parâmetro ou incorporado em um objeto não remoto em um parâmetro) deve ser declarado como uma interface remota, não a classe de implementação dessa interface.

A interface remota deve, portanto, estender a interface java.rmi.Remote (ou outra interface remota que estenda java.rmi.Remote). Todavia, uma interface remota pode estender uma interface não remota na seguinte condição:

— a interface remota que estender uma interface não remota enquanto todos os métodos (se houver) da interface estendida satisfazer todos os requisitos de declaração de métodos remotos.

Por exemplo, a interface a seguir BankAccount define uma interface para acessar uma conta bancária. Esta contem os métodos remotos de deposito, retirada e saldo da conta:

public interface BankAccount extends java.rmi.Remote {

      public void deposit(double amount)

            throws java.rmi.RemoteException;

      public void withdraw(double amount)

   throws OverdrawnException,   java.rmi.RemoteException;

      public double getBalance()

            throws java.rmi.RemoteException;

}

No próximo exemplo mostra uma interface remota beta que estende a interface java.rmi.Remote e também uma interface não remota com métodos remotos:

public interface Alpha {
      public final String okay = "constants are okay too";

      public Object foo(Object obj)
            throws java.rmi.RemoteException;

      public void bar() throws java.io.IOException;

      public int baz() throws java.lang.Exception;
}

public interface Beta extends Alpha, java.rmi.Remote {
      public void ping() throws java.rmi.RemoteException;
}
 

 

            2.3.2 A Classe RemoteException

A Classe RemoteException é a super-classe de lançamento de exceções  por RMI enquanto a execução dos métodos remotos. Para assegurar a robustez das aplicações usando sistema RM, cada método remoto declarado em interface remota deve especificar Java.rmi.RemoteException (ou uma de suas superclasses como java.io.IOException ou java.lang.Exception) em sua cláusula throws.

Algumas razões para a invocação de método remoto falhar e acionar a clausula throws são:

            — Falha na comunicação

            — Falha durante envio ou recebimento de parâmetro ou valor de retorno

            — Erro de protocolo

A Classe RemoteException é uma exceção de verificação (deve ser tratada pela chamada de uma método remoto e é controlada pelo compilador), não uma exceção de tempo de execução.

            2.3.3 A Classe RemoteObject e suas Subclasses

As funções servidor RMI são provenientes de java.rmi.server.RemoteObject e suas Subclasses, java.rmi.server.RemoteServer e java.rmi.server.UnicastRemoteObject e java.rmi.activation.Activable.

            — a classe java.rmi.server.RemoteObject prove implementação para os métodos java.lang.Object, hashCode, equals e toString que são versionada para objetos remotos.

            — os métodos necessários para criar objetos remotos e exporta-los (deixar disponíveis para clientes remotos) são fornecidos pelas classes UnicastRemoteObject e Activatable. A subclasse identifica a semântica da referencia remota, por exemplo qualquer que seja o servidor é um objeto remoto simples ou um objeto remoto Activatable (aquele que executa quando chamado)

            — a classe java.rmi.server.UnicastRemoteObject define uma singularidade (unicast ou  um-pra-um) no objeto remoto cujas referencias são validas apenas quando o processo servidor esta executando.

            — a classe java.rmi.activation.Activatable é uma classe abstrata que define um objeto remoto activatable que inicia a execução quando seus métodos remotos são invocados e pode se desligar quando necessário.

            2.4 Implementando uma interface remota

As regras gerais implementar uma interface remota são a seguintes:

            — a classe normalmente extends java.rmi.server.UnicastRemoteObjects, herdando assim o comportamento remoto provido pelas classes java.rmi.server.RemoteObject e java.rmi.server.RemoteServer.

            — a classe pode implementar qualquer quantidade de interfaces remotas.

            — a classe pode estender outra classe de implementação remota.

            — a classe pode definir métodos que não aparecem na interface, mas esses métodos só podem ser usados localmente e não serão disponíveis remotamente.

Por exemplo a seguir a classe BankAccImpl.java implementa a interface BankAcc

public class BankAccImpl extends java.rmi.server.UnicastRemoteObject

    implements BankAcc {

     private double balance = 0.0;

     public BankAccImpl() throws java.rmi.RemoteException{

         super();

     }

     public void withdraw(double value) throws java.rmi.RemoteException {

         balance = balance – value;

     }

public void deposit(double value) throws  java.rmi.RemoteException {

         balance = balance + value;

     }

public double balance() throws java.rmi.RemoteException {

         System.out.println(“Client viu saldo: “+balance);

         return balance;

     }

}

Note que, se necessário, a classe que implementa a interface remota pode estender outra classe alem da java.rmi.server.UnicastRemoteObject.

Entretanto, a classe de implementação deve então, assumir a responsabilidade pela exportação do objeto (cuidado pelo construtor da UnicastRemoteObject) e por implementar (se necessário) a semântica remota correta de hashCode(), equals() e toString() de java.lang.Object.

            2.5 Parâmetros Passados em RMI

Um argumento ou valor de retorno, de um objeto remoto pode ser qualquer objeto que seja serializable. Isto inclui tipos primitivos, objetos remotos e objetos não remotos que implementam a interface java.io.Serializable. Para mais detalhes de como criar classes serializable acesse java.sun.com na parte de documentação ver “Java Object Serialization Specification”. Classes para parâmetros e valor de retorno, que não estão disponíveis localmente são transferidos dinamicamente pelo sistema RMI. Ver o capitulo de “Carregamento Dinamico de Classes” para mais informações de como RMI transfere classes em parâmetros e valores de retorno quando lê parâmetros e valores de retorno e exceções.

            2.6 Localizando Objetos Remotos

Um servidor de amarração de nomes simples é fornecido para armazenar referencias nomeada de objetos remotos. Uma referencia de objeto remoto  pode ser armazenada usando base-URL em método da classe java.rmi.Naming

Para um cliente invocar um método de um objeto remoto, primeiro o cliente deve obter as referencias do objeto. O sistema RMI prevê um simples amarração de servidor de nomes que permita obter objetos remotos em dado hospedeiro. A classe java.rmi.Naming prevê Localizador Uniforme de Recursos (URL) embasado em métodos para localizar, vincular, desvincular, listar os nomes objetos pareados mantidos em um determinado host e porta.

3.0 Visão Geral do Sistema RMI

            3.1 Stub e Skeleton

O RMI utiliza um mecanismo padrão para comunicar com objetos remotos: Stub e Skeleton (utilizados em sistemas RPC). Stub para um objeto remoto atua como representante local cliente ou mandato para objeto remoto. O solicitante invoca o método local stub com a responsabilidade de chamar o método de objeto remoto. Em RMI, um stub implementa para um objeto remoto o mesmo conjunto de interfaces remotas que o objeto remoto implementou.

Quando um método stub é chamado faz o seguinte:

            — inicia a conexão com a JVM que contem o objeto remoto,

            — guia os parâmetro para JVM remota (escreve e transmite),

            — espera pelos resultados de uma invocação de método,

            — para transferência (lê) o valor de retorno ou exceção retornada, e

            — retorna o valor ao solicitante.

O Stub oculta a serialização dos parâmetros e a comunicação a nível de rede a fim de apresentar um mecanismo simples de invocação ao solicitante.

Na JMV remota, cada objeto remoto corresponde a um skeleton (no ambiente apenas Java2, skeleton não é requerido). O skeleton é responsável por despachar a chamada para a atual implementação do objeto remoto. Quando o skeleton recebe de entrada uma invocação de método remoto, faz o seguinte:

            — Le os parâmetros para o método remoto,

            — invoca o método na atual implementação do objeto remoto, e

            — escreve e transmite o resultado (valor de retorno ou exceção) para o solicitante.

No Java 2 SDK um adicional protocolo stub foi introduzido eliminando a necessidade por skeletons. Código genérico é usado para realizar as funções exercicidas por skeleton in JDK 1.1. Stub e skeletons são gerados apartir do compilador RMI (rmic).

            3.2 Uso de Thread em RMI

Métodos expedidos pelo RMI em tempo de execução para uma implementação de um objeto remoto pode ou não pode executar uma thread separada. A execução RMI faz sem garantias a respeito de mapeamento da invocação a objetos remoto com threads. Desde a invocação de método remoto no mesmo objeto remoto pode executar concomitantemente, a implementação do um objeto remoto precisa ter certeza de sua implementação segura thread.

            3.3 Coletor de lixo em objetos remotos

Em sistemas distribuídos, apenas em sistema local, é desejável apagar automaticamente aqueles objetos remotos que não são mais referenciados. Isso livra o programador da necessidade de se manter a par dos objetos remotos cliente para que ele possa finalizar de modo adequado. RMi usa a referencia de um algoritmo coletor de lixo similar ao ‘Modula-3’s Network Objects’(ver “Network Objects” by Birrell, Nelson, and Owicki, Digital Equipment Corporation Systems Research Center Technical Report 115, 1994).

Para realizar a contagem referencia do coletor de lixo, o RMI em tempo de execução mantém registro de todas as referências ao vivo em cada máquina virtual Java. Quando a referencia viva entra em uma JVM, a contagem de referencias é incrementada. A primeira referencia a um objeto envia uma mensagem “referenciada” ao servidor do objeto. Como sendo feito ao vivo, são consideradas sem referencias na JVM, são decrementadas. Quando a ultima referencia é descartada, uma mensagem “não referenciada” é enviada ao servidor. Muitas sutilezas existentes no protocolo, a maioria destes estão relacionados com a manutenção da ordenação das mensagens referenciadas e não referenciadas de forma a garantir o objetos não é coletado prematuramente.

Quando um objeto não é referenciado em nenhum cliente, o RMI runtime refere-se a ele usando uma referencia fraca. A referencia fraca permite ao coletor de lixo da JVM descartar o objeto se não houver outras referencias locais ao objeto existente. O algoritmo de coletor de lixo distribuído interage com o coletor de lixo da JVM local na forma usual, mantendo normal ou fraca as referencias a objetos.

Enquanto uma referencia local de um objeto existe, não pode ser descartado por coletor de lixo e que pode ser passado em chamadas remotas ou devolvidos aos clientes. Passando um objeto remoto adiciona o identificador para a máquina virtual em que foi passado para o conjunto de referencia. Um objeto remoto a necessidade sem notificação referencia deve implementar a interface java.rmi.server.Unreferenced. Quando uma referencia deixa de existir, o método unreferenced será invocado. Unreferenced é chamado quando o conjunto de referencias é vazio para que ele possa ser chamado mais de uma vez. Objeto remoto é apenas coletado quando não houver mais referencias, seja local ou remota.

Observe que se uma partição da rede existir entre cliente e servidor de objetos remotos, é possível ocorrer uma coleta prematura de objetos remotos (uma vez que o transporte possa parecer que o cliente deixou de funcionar). Por causa da possibilidade de coleta prematura, referencias remotas não podem garantir a integridade da referencia; em outras palavras, é sempre possível uma referencia remota, de fato, pode se referir a um objeto inexistente. Uma tentativa de usar essa referencia vai gerar um RemoteException que deve ser tratada através da aplicação.

            3.4 Carregamento Dinâmico de Classes

RMI permite parâmetro, valores de retorno e exceções passada nas chamadas RMI a qualquer objeto que é serializable. RMI usa um mecanismo de serialização de objetos para transmitir dados de uma JVM a outra e também anota  o fluxo de chamadas com as informações de localização adequada, de modo que os arquivos de definição de classes podem ser carregados no receptor.

Quando parâmetros e valores de retorno para uma invocação de método remoto são transmitidas torna-se vivo o objeto na JVM receptora, definição da classe são requerida para todos os tipos de objetos no laço. O processo de transferência primeiro tenta resolver as classes por nome no seu contexto local de carregamento de classes (o contexto de carregamento de classe na tread atual). RMI também provê uma facilidade para carregamento dinâmico as definições das classes do atual tipo de objeto passa como parâmetro e valor de retorno para invocação do método remoto a partir de locais de rede especificado pelo parâmetro de transmissão. Isso inclui o downloading dinâmico da classe stub remota correspondente das classes implementação do objeto remoto particular (e usado para conter referencias remotas) bem como qualquer outro tipo passado de valor de retorno em chamadas RMI, como uma subclasse de um tipo de parâmetro declarado, não que já está declarado no contexto de carregamento de classes do lado (des)transmissor.

Para suportar carregamento dinâmico de classes, o RMI runtime usa uma subclasse especial java.io.ObjectOutputStrem and java.io.ObjectInputStream para o stream ordenador que usa para ordenar e desordenar (eviar e receber) parâmetros RMI e valores de retorno. Essas subclasses respectivamente sobre escrevem o método annotateClass do ObjectOutputStream e o método resolveClass do ObjectInputStream para comunicar informações sobre onde localizar arquivos class contendo as definições para as classes correspondentes a classe descrita no stream.

Para cada descritor classe escrita em um ordenador stream RMI, o método annotateClass adiciona no stream o resultado da chamada java.rmi.server.RMIClassLoader.getClassAnnotation para a classe objeto, que pode ser null ou pode ser objeto String representando código-base caminho URL (uma lista separada por espaços URL) a partir do qual o ponto final remoto deve baixar o arquivo de definição da classe para uma determinada classe.

Para cada descritor classe lida em um ordenador stream RMI, o método resolveClass lê um objeto simples a partir do stream. Se o objeto é uma String (e o valor da propriedade java.rmi.server.useCodebaseOnly não for true) , então resolveClass retorna o resultado da chamada RMIClassLoader.loadClass com a anotação objeto String como o primeiro parâmetro e o nome da classe desejada no descritor da classe como o segundo parâmetro. Caso contrário, resolveClass retorna o resultado da chamada RMIClassLoader.loadClass com o nome da classe desejada como parâmetro único.

Ver a documentação Java sobre The RMIClassLoader Class” para mais detalhes de como RMI faz carregamento de classes.

            3.5 RMI através de firewalls via proxies

A camada de transporte RMI normalmente aceita abrir diretamente sockets entre hosts na internet. Muitas intranets, entretanto, tem firewalls que não permitem isso. Transporte RMI padrão, portanto, provê duas alternativas em mecanismos baseados HTTP para permitir clientes atrás de um firewall invocar um método em um objeto remoto que reside fora de um firewall.

Conforme descrito, o mecanismo com base HTTP que a camada de transporte RMI usa para chamadas apenas se aplica aos firewalls com servidores Proxy HTTP.

            3.5.1 Como uma chamada RMI é empacotada dentro do protocolo HTTP

Para chegar ao lado de fora de um firewall, a camada de transporte encaixa uma chamada RMI com protocolo HTTP de confiança do firewall. Os dados da chamada RMI é enviado com o corpo de uma postagem de requisição HTTP, e retorna informação de volta em corpo de uma resposta HTTP. A camada de transporte formula a postagem de requisição com uma de duas maneiras:

  1. Se o firewall Proxy vai enviar uma requisição HTTP direciona em uma porta arbitrária na maquina host, então ele é encaminhado diretamente para a porta a qual o servidor está executando RMI. O padrão da camada de transporte RMI na máquina alvo está escutando com socket servidor que é capaz de compreender e decodificar chamadas RMI dentro pedidos POST.
  2. Se o firewall Proxy vai transmitir pedidos HTTP dirigido apenas a certas conhecidas portas HTTP, então a chamada é direcionada para um servidor HTTP escutando na porta 80 da máquina host, e um script CGI é executado para transmitir a chamada a porta do servidor alvo RMI na mesma máquina.

 

3.5.2 Fábrica de sockets padrão

A implementação de transportes RMI inclui uma extensão da classe java.rmi.server.RMISocketFactory, que é o padrão do provedor de recursos para o cliente e servidor sockets usado para enviar e receber chamadas RMI, esta fábrica padrão de sockets pode ser obtida através do método java.rmi.server.RMISocketFactory.getDefaultSocketFactory.

Esta fábrica de sockets padrão cria sockets que transparentemente fornece o mecanismo de tunelamento do firewall da seguinte forma:

            — o socket cliente primeiro tenta uma conexão direta com socket. Sockets cliente tentam automaticamente conexões HTTP com hosts que não pode ser contatado com socket direto se os resultados da ligação de sockets direta for lançado em qualquer um java.net.NoRouteToHostException  ou um java.net.UnknownHostException. Se uma conexão direta com socket lançar qualquer outra exceção, como java.net.ConnectionException, uma conexão HTTP não será tentada.

            — Socket Servidor automaticamente detecta se uma conexão recém admitida é um requerimento HTTP POST, e então, retorna um socket apenas que irá expor o corpo da solicitação para o transporte e seu formato de saída como uma resposta HTTP.

Sockets do lado cliente, com comportamento padrão, são fornecidos pelo método fabrica java.rmi.server.RMISocketFactory.createSocket.

Sockets do lado servidor, com comportamento padrão, são fornecidos pelo método fabrica java.rmi.server.RMISocketFactory.createServerSocket

            3.5.3 Configurando o Cliente

Não há nenhuma configuração especial necessária para permitir que o cliente envie chamadas RMI através de um firewall.

O cliente pode, no entanto, desabilitar o empacotamento de chamadas RMI como solicitações HTTP, definindo a propriedade java.rmi.server.disableHttp para o valor booleano verdadeiro.

            3.5.4 Configurando o Servidor

Nota – O nome do host não deve ser especificado como o endereço IP do host, porque alguns firewall proxy não vai encaminhar como nome host.

Em condição para um cliente fora do domínio do host do servidor ser capaz de invocar métodos em objetos remotos, o cliente deve ser capaz de encontrar o servidor. Para fazer isso, as referências remotas que as exportações devem conter o servidor deve ser totalmente qualificado do host.

Dependendo da plataforma do servidor e ambiente de rede, esta informação pode ou não estar disponível para a máquina virtual Java no qual o servidor está em execução. Se não estiver disponível, o host com o nome totalmente qualificado deve ser especificado com a propriedade java.rmi.server.hostname ao iniciar o servidor.

Por exemplo, use este comando para iniciar a classe servidor RMI ServerImpl na máquina chatsubo.javasoft.com:

java -Djava.rmi.server.hostname=chatsubo.javasoft.com ServerImpl

 

Se o servidor não oferecer suporte a clientes RMI atrás de firewalls podem transmitir as portas arbitrárias, use essa configuração:

  1. Um servidor HTTP escutando na porta 80.
  2. Um GCI script localizado em URL alias
/cgi-bin/java-rmi.cgi

 

Este script:

— Invoca interpretador local da linguagem de programação Java para executar uma classe interna à camada de transporte que encaminha a solicitação a porta adequada do servidor RMI.

— Define as propriedades da máquina virtual Java com os mesmos nomes e valores, como o CGI 1.0 definindo as variáveis de ambiente.

Um script de exemplo é fornecido na distribuição RMI para o Solaris e Windows 32. Note que o script deve especificar o caminho completo para o interpretador da linguagem de programação Java no servidor.

            3.5.5 Problemas de Desempenho e Limitações

Chamadas transmitidas via requisições HTTP pelo menos uma ordem de magnitude mais lento do que as enviadas através de sockets diretos, sem considerar atrasos transmissão de proxy.

Como as solicitações HTTP só pode ser iniciado em uma direção através de um firewall, um cliente não pode exportar seus próprios objetos remotos fora da firewall, pois um host fora do firewall não pode iniciar uma invocação de método de volta no cliente.

Referência:

http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html

  1. Deixe um comentário

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: