Remote Method Invocation (RMI)

Remote Method Invocation (RMI) November 1, 2009 Sumário RMI Conceito Implementação Exemplos Java RMI Características Objectos Remotos e Interfaces Remotas Implementação de Java RMI Argumentos e serialização Transferência de código Localização de objectos remotos Segurança Tempo de vida dum objecto remoto Passos no desenvolvimento de aplicações Transferência de código

Sumário RMI Conceito Implementação Exemplos Java RMI Características Objectos Remotos e Interfaces Remotas Implementação de Java RMI Argumentos e serialização Transferência de código Localização de objectos remotos Segurança Tempo de vida dum objecto remoto Passos no desenvolvimento de aplicações Transferência de código RMI e RPC RPC significou um passo muito grande em direcção à transparência de distribuição na programação: a maior parte do código que mostra a natureza distribuída da aplicação pode ser: gerada automaticamente, p.ex. por rpcgen; isolada da parte restante do código; o código (texto) a desenvolver pelo programador praticamente não depende da distribuição, e o programador pode quase ignorá-la: embora esta prática seja questionável. Com a adopção generalizada da programação baseada em objectos, estender RPCs a objectos era inevitável: RMI (Remote Method Invocation) é RPC baseada em objectos.

Programação Distribuída Baseada em Objectos O conceito de objecto é especialmente adaptado para aplicações distribuídas. Um objecto agrega os dados e as operações que operam sobre esses dados. Objectos podem residir em diferentes computadores, ligados por uma rede. A interação entre objectos é feita através de invocação remota de métodos (remote method invocation), i.e. RPC para objectos: Computador 1 Objecto Computador 2 Objecto Dados Metodos Dados Metodos Objecto Objecto Dados Metodos Dados Metodos Invocação Local vs. Invocação Remota process Local MI Remote MI object host Um caso particular da invocação remota envolve objectos em processos diferentes do mesmo computador. Note-se que cada objecto reside apenas num processo, i.e. o estado dos objectos não é distribuído.

Transparência do Cliente e Proxy-Objects A invocação dum método num objecto remoto deverá ser feita de modo semelhante à invocação dum método num objecto local. Com RPCs, o truque é invocar uma função local o client stub a qual se encarrega da comunicação entre processos. Com RMI, o truque é invocar o método sobre um objecto local o proxy object, o qual não executa o método, mas encarrega-se de o passar ao objecto remoto. Transparência do Lado do Servidor e Skeletons A transparência do lado do servidor é conseguida com recurso ao conceito de skeleton. O skeleton é um objecto que: extrai (unmarshals) os argumentos da mensagem recebida e invoca o método apropriado do objecto invocado (local); constrói a mensagem resposta com os resultados da invocação do método e envia-la.

RMI: Arquitectura de Implementação Client machine Server machine Client invokes a method Client Proxy Client OS Same interface as object Skeleton invokes same method at object Server Skeleton Server OS Object State Method Interface Network Marshalled invocation is passed across network Alternativamente, a funcionalidade do skeleton pode ser implementada pela classe do objecto remoto. RMI - Exemplos CORBA RMI Heterogeneidade é a característica distintiva. O objecto e o cliente podem ser implementados usando linguagens diferentes: Para o efeito, CORBA define uma Interface Definition Language (IDL), funcionalmente análoga a RPCL. CORBA suporta inclusivamente linguagens não-baseadas em objectos, como C ou Cobol. Java RMI Dependente da linguagem.

Sumário RMI Conceito Implementação Exemplos Java RMI Características Objectos Remotos e Interfaces Remotas Implementação de Java RMI Argumentos e serialização Transferência de código Localização de objectos remotos Segurança Tempo de vida dum objecto remoto Passos no desenvolvimento de aplicações Transferência de código Java RMI: Características (1/2) Integrada na linguagem Java: mais fácil de usar não há necessidade de usar linguagens de especificação de interfaces, p.ex. Interface Definition Language (IDL) em CORBA. Invocação de métodos remotos usa a mesma sintaxe que a invocação de métodos locais, mas... Distribuição dos objectos é exibida intencionalmente: a invocação dum método remoto pode assinalar uma excepção RemoteException. para que os métodos dum objecto possam ser invocados remotamente, a classe correspondente deverá implementar uma interface remota.

Java RMI: Características (2/2) Benificia da mobilidade de: código (classes); objectos; entre computadores suportada por Java. Distributed Garbage Collection: um objecto desaparece automaticamente quando não pode ser acedido. Objectos Remotos e Interfaces Remotas Objectos remotos são objectos cujos métodos podem ser invocados duma JVM diferente daquela onde residem. Um objecto remoto tem que implementar uma interface remota, i.e. o seu tipo é um subtipo da interface Remote: Permite que o compilador de Java gere o código necessário para realizar a comunicação entre objectos em JVMs distintas. A não-localidade dum objecto remoto é exposta aos programadores dos clientes : Todos os métodos da interface Remote têm que assinalar RemoteExceptions. Um objecto remoto pode incluir métodos não invocáveis remotamente: Só métodos declarados em interfaces remotas podem ser invocados remotamente.

Remote Interface: Exemplo A interface remota dum servidor de eco pode ser: import java.rmi.remote; import java.rmi.remoteexception; public interface Echo extends Remote { String echo(string str) throws RemoteException; } Esta interface suporta um único método remoto: echo, o qual retorna a string que lhe é passada como argumento. O método echo dum objecto que implemente esta interface pode ser invocado remotamente. I.e., pode ser invocado por um objecto a executar numa máquina virtual de Java (JVM) diferente. Acesso a Objectos Remotos Para usar um objecto remoto, um cliente tem que conhecer a interface remota desse objecto: i.e. os métodos desse objecto que podem ser invocados remotamente. A sintaxe de invocação de métodos remotos é semelhante à de invocação de métodos locais: Echo montanha =...; // lookup montanha String eco; try { eco = montanha.echo( Uh! Uh! ); } catch ( RemoteException e) {... } Contudo, os clientes têm que processar excepções do tipo RemoteException.

Exemplo: Implementação da interface Echo import java.rmi.*; import java.rmi.server.unicastremoteobject; public class Echo_Impl extends UnicastRemoteObject implements Echo { public Echo_Impl() throws RemoteException { super(); /* Actually this is not needed */ } } public String echo(string str) { return str; } Java RMI e a JVM A JVM não conhece objectos remotos: A JVM só suporta a invocação de métodos sobre objectos locais. Java RMI é uma camada de SW sobre a JVM, não faz parte dela. Java RMI implementa RMI usando os mecanismos do costume: stubs do lado do cliente; skeletons do lado do servidor.

Java RMI Stubs Em Java RMI, o stub dum objecto remoto é um objecto local (em relação ao cliente) que representa esse objecto remoto. Daí a designação comum de proxy object. Uma referência remota é, de facto, uma referência para o stub correspondente. O stub dum objecto remoto; implementa a sua interface remota contém o seu endereço Essencialmente, as tarefas executadas pelo stub são: 1. marshalling dos argumentos do método; 2. envio do pedido de execução do método através da rede ; 3. recepção da resposta; 4. unmarshalling do resultado da invocação. Java RMI Servers (1/2) Na primeira versão de Java RMI, a funcionalidade do lado do objecto remoto foi repartida por 2 tipos de objectos: objectos do tipo RemoteServer executam o processamento que é independente da interface remota: p.ex., esperar pela recepção de pedidos de invocação. objectos do tipo skeleton executam o processamento que depende da interface remota: unmarshalling dos argumentos; invocação do método do objecto remoto; marshalling dos resultados.

Java RMI Servers (2/2) A partir de Java 1.2, objectos do tipo skeleton deixaram de ser necessários: objectos do tipo RemoteServer passaram a ser capazes de fazer também as tarefas dos skeleton. Java RMI oferece a classe UnicastRemoteObject, a qual estende RemoteServer, e oferece funcionalidade mínima para aplicações baseadas em RMI: O objecto termina quando o processo que o criou termina. Usa TCP na comunicação com os clientes. Argumentos de Métodos Remotos Os argumentos de ou o valor retornado por um método remoto podem ser: 1. tipos simples. Por exemplo, boolean, char, byte, short, int, long, float ou double; 2. objectos remotos, i.e. que implementam a interface Remote; 3. objectos locais serializáveis, i.e. que implementam a interface Serializable (incluindo, Strings e arrays). No caso de objectos locais, RMI passa uma cópia do objecto: como o objecto é serializável tal é possível; note-se que Java RMI não actualiza o objecto passado caso o método remoto o tenha modificado. Atenção: Uma referência para um objecto remoto é de facto uma referência para o objecto proxy respectivo.

Objectos Remotos vs Objectos Serializáveis Machine A Machine B Local reference L1 Local object O1 Remote reference R1 Remote object O2 Client code with RMI to server at C (proxy) New local reference Copy of O1 Remote invocation with L1 and R1 as parameters Machine C Copy of R1 to O2 Server code (method implementation) Na prática é como se objecto remoto O2 fosse passado por referência, enquanto que o objecto local (serializável) O1 é passado por valor. Semânticas diferentes, transparência turva. Serialização em Java (1/2) Java RMI usa o mecanismo de serialização de Java para passar os argumentos e o valor retornado. Em Java, serialização dum objecto consiste na conversão desse objecto numa sequência de bytes de modo a permitir: o seu armazenamento no disco, para posterior reincarnação; ou a sua migração para uma outra JVM. A reconstituição dum objecto a partir da sua representação serializada designa-se por deserialização. Para que um objecto seja serializável deverá implementar a interface java.io.serializable. A JVM implementa um procedimento de serialização por omissão que pode ser usado pela grande maioria dos objectos: desde que a definição da sua classe declare que implementa a interface java.io.serializable.

Serialização em Java (2/2) Se um objecto tiver campos que são referências para outros objectos, estes últimos deverão ser serializáveis para que o primeiro também o seja: para serializar o primeiro objecto, há que serializar os outros; cada objecto só é serializado uma vez, mesmo que seja referenciado múltiplas vezes. Por razões de eficiência, os métodos duma classe não são incluídos na sequência de bytes criada pela serialização: a JVM inclui apenas um identificador da classe a que o objecto pertence. Class Downloading em Java e RMI Problema: Como é que um método remoto pode invocar o método dum objecto não remoto que lhe é passado como argumento? Os métodos dum objecto não fazem parte da sua representação serializada. Solução: Usando as facilidades de transferência de código em Java: Note-se que esta transferência pode não ser necessária, se a classe estiver disponível localmente. A capacidade de transferência de classes através da rede pode também ser usada pelo cliente para carregar o proxy object. não há necessidade de manter todas as classes em todos os computadores;

Localização dum Objecto O acesso a um objecto remoto é feito usando uma referência para um proxy desse objecto: montanha.echo() Problema: como é que se obtém uma referência remota, i.e. para o proxy dum objecto remoto? Tecnicamente, através do valor de retorno dum método. Solução: semelhante ao portmapper de RPC: Java RMI oferece um serviço de nomes básico: o rmiregistry. O rmiregistry é um programa e tem que executar nos computadores que disponibilizam objectos remotos. O servidor regista o objecto com um nome (binds) no rmiregistry local. O cliente solicita uma referência para um objecto remoto ao rmiregistry no computador onde o objecto reside. O rmiregistry e a Interface Registry O rmiregistry é uma aplicação que implementa a interface Registry: void rebind(string name, Remote obj); void bind(string name, Remote obj); void unbind(string name, Remote obj); Remote lookup(string name); String []list(); Se incorrectamente usado, o rmiregistry pode impedir o uso de classes importadas : If you do start the rmiregistry and it can find your stub classes in CLASSPATH, it will not remember that the loaded stub class can be loaded from your server s code base,[...], do Tutorial on-line da Sun sobre RMI.

A classe Naming Permite aceder a objectos que implementam Registry. Suporta os seguintes métodos: void rebind(string name, Remote obj); void bind(string name, Remote obj); void unbind(string name, Remote obj); Remote lookup(string name); String []list(); onde name é um URL sem o método de acesso: //computername:port/objectname sendo //computername:port/ a localização do rmiregistry. bind() difere de rebind() na medida em que assinala uma excepção se name já tiver sido registado. O rmregistry não é um servidor global: O cliente tem que saber onde se encontra o objecto. Exemplo: Registo e Localização do Objecto O servidor tem que registar o objecto remoto: Echo montanha; try { montanha = new Echo_Impl(); Naming.rebind( alpes, montanha);... } catch ( RemoteException e) {... } O cliente tem que o localizar (em i01co2213): Echo montanha; try { montanha = Naming.lookup( //i01co2213/alpes );... } catch ( RemoteException e) { // Naming.lookup() is RMI... }

Arquitectura de Java RMI RMI Client 5. return stub class 4. request stub class Web server 2. lookup object 3. return object reference 7. return result 6. remote invocation RMIregistry 1. register object RMI server RMI e Segurança Problema: Java RMI pode exigir a transferência de código (classes) de máquinas remotas: este código é uma potencial ameaça à segurança. Solução: Usar um Security Manager: um objecto que controla o acesso aos recursos locais. Java 1.0 suportava um modêlo de segurança do tipo sandbox: Código local não tinha restrições, para além das impostas pelo SO; Código importado só podia aceder aos recursos (limitados) disponíveis na sandbox. A partir de Java 1.2 pode-se sujeitar todo o código, independentemente de ser ou não local, a controlo de acesso, sendo este determinado pela security policy em vigor.

Política de Segurança (Security Policy) e Permissões A política de segurança define as permissões de código com base na sua origem, sendo configurável quer pelo utilizador quer pelo administrador. Cada permissão especifica o tipo de acesso permitido a um determinado recurso, tal como: Lêr ou escrever um ficheiro ou directório. Estabelecer uma conexão para um determinado endereço IP e porto. Algumas operações sobre a própria JVM requerem permissões: Substituir o ClassLoader. Substituir o SecurityManager. Alterar a política de segurança. Permissões Internamente, permissões são objectos. P.ex.: java.io.filepermission Uma permissão tipicamente tem: Nome, que identifica o recurso a que se aplica; Lista de acções, que especifica as operações permitidas. permissão nome lista de acções java.io.filepermission /usr/lib/- read, execute java.net.socketpermission abc.com:54321 connect java.security.securitypermission setpolicy java.lang.runtimepermission createclassloader java.lang.runtimepermission setsecuritymanager Uma política de segurança é um conjunto de permissões, que determinam que operações um segmento de código pode executar. Naturalmente, a política de segurança é representada por um objecto (java.security.policy).

Inicialização do java.security.policy Na implementação referência, este objecto pode ser inicializado a partir de vários ficheiros de configuração. Por omissão usa: Um ficheiro de configuração para todo o sistema: ${java.home}/lib/security/java.policy Um ficheiro de configuração por utilizador: ~/.java.policy O ficheiro de configuração das propriedades de segurança permite especificar ainda outros ficheiros de configuração. ${java.home}/lib/security/java.security O ficheiro com a política de segurança pode ainda ser especificado quando da invocação da JVM: java -Djava.security.policy=somefile... Se a propriedade policy.allowsystemproperty o permitir pode ser activada no ficheiro de configuração das propriedades de segurança. Sintaxe dos Ficheiros de Políticas Consiste numa lista de elementos (entries): keystore é opcional (não usaremos, pelo menos para já); grant clausúla usada para especificar as permissões de código de acordo com algumas propriedades (consideraremos apenas a sua origem): Tem o seguinte formato (de facto omite regras): grant [codebase <URL>] { permission <class_name> <target> [, <action>];... } onde: codebase especifica a origem do código; permission especifica uma permissão, podendo um elemento grant incluir várias permissões. Pode ocorrer uma ou mais vezes.

Sintaxe dos Ficheiros de Políticas: Exemplos grant { permission java.net.socketpermission "*:1024-", "connect,accept"; permission java.net.socketpermission "abc.com:*", "connect,accept"; permission java.io.filepermission "/home/ann/public_html/classes/-", "read"; permission java.io.filepermission "/home/jones/public_html/classes/-", "read"; }; grant codebase "http://paginas.fe.up.pt/~ei77777/classes/" { permission java.security.allpermission; } policytool é uma aplicação que faz parte do J2SDK que oferece um GUI para auxiliar a edição de ficheiros de políticas. Security Manager (1/2) O Security Manager é um objecto que garante o cumprimento da política de segurança. Consiste apenas num conjunto de métodos, tais como: public void checkpermission(permission perm) throws SecurityException public void checkcreateclassloader( ) throws SecurityException Normalmente, um thread só pode executar uma operação se todos os métodos activos que invocou tiverem permissão para a executar. Tipicamente essa decisão é baseada na origem do código. Estes métodos são invocados por outros objectos quando executam certas operações. O Security Manager é um Reference Monitor.

Security Manager (2/2) O SecurityManager não é instalado por omissão. A instalação do SecurityManager pode ser feita: Pelo interpretador (JVM): java -Djava.security.manager... Pelo código:... System.setSecurityManager(new SecurityManager());... A política imposta pelo SecurityManager pode ser configurada através dos ficheiros de especificação da SecurityPolicy. O código do sistema invoca os métodos checkxxx do SecurityManager se este estiver instalado: Estes métodos por sua vez invocam o método checkpermission() do AccessController. Access Controller A partir de Java 1.2, o java.security.accesscontroller é a classe que, de facto, garante o cumprimento da política de segurança. Por concepção é mais fácil flexível que o SecurityManager e está sempre instalado (só static). Implementa uma política razoavelmente restritiva que pode ser usada na maioria dos casos. Naturalmente, pode invocar-se directamente da aplicação os métodos do AccessController. FilePermission perm = new FilePermission("/tmp/testFile", "read"); AccessController.checkPermission(perm); Se a política de segurança implementada pelo AccessController não fôr adequada, pode ser adaptada criando subclasses do java.lang.securitymanager Estas subclasses devem invocar os métodos do AccessController, sempre que tal faça sentido.

java.rmi.rmisecuritymanager java.rmi.rmisecuritymanager é uma sua subclasse do java.lang.securitymanager: Implementa exactamente os mesmos métodos. O RMISecurityManager deve ser usado com RMI sempre que há necessidade de transferir código dum computador remoto: O RMI class loader recusa-se a carregar qualquer classe, se não houver um Security Manager. O RMISecurityManager pode ser instalado de 2 modos: Através do código:... System.setSecurityManager(new RMISecurityManager());... Através da linha de comando: java -Djava.security.manager=java.rmi.RMISecurityManager... Arquitectura de Segurança em Java O Security Manager não é a história toda: Class repository Loaded class object Class verifier Class repository Java program Request class Loader for local classes Java interpreter Loader for remote classes Select appropriate loader Local site Remote site

Tempo de Vida dum Objecto Remoto A vida dum objecto chega ao fim quando deixa de ser referenciado: sem qualquer referência para o objecto, não é possível aceder-lhe. Para objectos locais: o garbage collector da JVM automaticamente detecta quando um objecto deixa de ser referenciado e liberta os recursos; quando a JVM termina, todos os objectos locais terminam. Para objectos remotos: as diferentes JVMs executam um algoritmo distribuído para fazer garbage collection; quando uma JVM termina, objectos remotos por ela criados podem não terminar. Por exemplo, o RMIregistry mantém uma referência para todos os objectos nele registados. Passos no Desenvolvimento com Java RMI 1. Concepção e implementação de servidor e clientes. Definição da interface remota, i.e. dos métodos que podem ser invocados remotamente. Implementação de objectos remotos, os quais devem implementar a interface remota definida. Implementação de clientes. 2. Compilação do código e geração de stubs: a compilação do código é feita usando javac; os stubs, a usar pelo cliente, podem ser gerados usando o rmic a partir do ficheiro.class da implementação: rmic Echo_Impl Nota: A partir de Java 5.0, Java RMI suporta a geração dinâmica de stubs. 3. Disponibilização do código, por exemplo num servidor HTTP: classes que precisem ser carregadas (downloaded) incluindo os stubs devem ser disponibilizadas num servidor HTTP.

RMI e Uploaded Code Aplicações (clientes ou servidores) que podem transferir código deverão instalar um Security Manager: import java.rmi.*; public class Echo_Client { public static void main(string[] args) { if(args.length!= 2) { System.out.println("Usage: java Echo_Client " + "srv_hostname obj_name"); return; } System.setSecurityManager(new RMISecurityManager()); try {... Se o código do stub pode ser uploaded há que inicializar a propriedade java.rmi.server.codebase na aplicação servidora, p.ex.: java -Djava.rmi.server.codebase=http://web/~pfs/echo_server/ Atenção ao rmiregistry Arquitectura de Java RMI RMI Client 2. lookup object 3. return object reference RMIregistry 5. return stub class 4. request stub class 7. return result 1. register object Web server 6. remote invocation RMI server

Sumário RMI Conceito Implementação Exemplos Java RMI Características Objectos Remotos e Interfaces Remotas Implementação de Java RMI Argumentos e serialização Transferência de código Localização de objectos remotos Segurança Tempo de vida dum objecto remoto Passos no desenvolvimento de aplicações Transferência de código Leitura Adicional Capítulo 10 de Tanenbaum e van Steen, Distributed Systems, 2nd Ed. Secção 10.1 Architecture, excepto Subsecção 10.1.3. Secção 10.3 Communication, excepto Subsecção 10.3.5. Java RMI Specification, da Sun Java Security Overview, da Sun, Secções 1, 2 e 8 Security Policy in Java SE 6, da Sun Permissions in Java SE 6, da Sun