Attivazione di oggetti remoti.

L'utilizzo del pattern Factory risolve in maniera

piuttosto agile alcune delle limitazioni imposte

dal modello RMI: con tale tecnica infatti è

possibile attivare oggetti al momento della

effettiva necessità su richiesta del client, e in

modo esclusivo. Rispetto alla situazione

standard, il problema dello spreco delle risorse

e quindi ridotto, dato che, tranne che per il

factory remoto, gli altri oggetti remoti sono

inizializzati al momento dell'effettivo bisogno.

Con il rilascio della piattaforma Java 2 è stata

introdotta una tecnica alternativa, che si basa

su un altro tipo di oggetti remoti: invece che

derivare da UnicastRemoteObject, in questo

caso l'oggetto attivabile su richiesta del cliente

estende direttamente la classe java . rmi .activation .

Activatable. Questa maggiore flessibilità permette

un più razionale utilizzo delle risorse, senza

sconvolgere di fatto l'organizzazione delle

applicazioni, dato che dal punto di vista del

client RMI il meccanismo di invocazione remota

è identico al caso standard. Le operazioni da

fare per modificare un oggetto remoto riguardano,

come accennato in precedenza, esclusivamente

il lato server. L'oggetto remoto in questo caso

deve essere modificato nel seguente modo:

1 estendere la classe Activatable invece che

UnicastRemoteObject

import java . rmi .*;

import java . rmi .activation .*;

public class Active extends Activatable

si noti l'import del package java .rmi . activation

al posto del java . rmi . Server;

2 rimuovere o commentare il costruttore vuoto

che prima era obbligatoriamente necessario

definire; al suo posto mettere la versione riportata

di seguito

public Active (ActivationId id, MarshallObject data) throws Exception {

super (id, data) ;

}

A questo punto formalmente l'oggetto non è più

un oggetto remoto ma è detto attivabile. Per quanto

riguarda l'applicazione server vi è un'altra importante

differenza: nel caso degli oggetti remoti essa doveva

restare attiva per tutto il tempo necessario all'utilizzo

degli oggetti remoti da parte del client. Adesso invece

gli oggetti remoti sono gestiti da un demone apposito

(rmid), ed il server deve esclusivamente effettuare

l'operazione di registrazione, e dopo che tale installazione

è terminata, il server può uscire. Per questo motivo

in genere si utilizzano nomi del tipo setupxxx invece

di serverxxx. Il processo di installazione si traduce

nel creare un ambiente di lavoro per l'oggetto attivabile

(quello che si definisce ActicationGroup), settando

eventualmente delle variabili che verranno utilizzate al

momento della inizializzazione dell'oggetto attivabile;

successivamente tale setup-class provvede a registrare

tale oggetto nel registro RMI. D i seguito sono

riportate sinteticamente le operazioni da svolgere per

installare un oggetto attivabile.

Import java . rmi .*;

import java . rmi .activation.*;

import java . util . Properties ;

/ / installare un security manager appropriato

/ / creare un'istanza di ActivationGroup

Properties props;

props = (Properties) System . GetProperties ( ) . clone ( ) ;

ActivationGroupDesc Agd ;

Agd = new ActivationGroupDesc (props, null);

ActivationGroupID Agi;

Agi = ActivationGroup.getSystem ( ) .registerGroup (Agd) ;

ActivationGroup . CreateGroup (Agi . Agd, 0 ) ;

Si deve infine creare una istanza ActivationDesc la

quale fornisce tutte le informazioni di cui il demone

rmid necessita per creare le istanze vere e proprie

degli oggetti attivabili. Queste informazioni

consistono di varie parti, come ad esempio il nome

della classe, la collocazione del codice remoto, e

una istanza della classe che serve per passare una

configurazione di inizializzazione all'oggetto

remoto. Ad esempio si può scrivere

ActivationDesc Desc;

Desc = new ActivationDesc ( “EchoApp . EchoImpl “ , location, data) ;

La classe MarshalledObject, introdotta con il JDK 1.2,

contiene un bytestream dove viene memorizzata una

rappresentazione serializzata dell'oggetto passato al

suo costruttore.

Public MarshalledObject (Object obj) throws IOException

Il metodo get restituisce una copia non serializzata

dell'oggetto originale. La modalità con cui vengono

effettuate le operazioni di serializzazione e deserializzazione

sono le stesse utilizzate durante il processo marshalling

dei parametri durante una invocazione RMI di un

metodo remoto. Durante la serializzazione l'oggetto

viene memorizzato con il codebase dell'URL da dove

la classe eventualmente può essere scaricata.

Inoltre ogni oggetto remoto memorizzato all'interno

del MarshalledObject è rappresentato con una

istanza serializzata dello stub dell'oggetto stesso.

La classe MarshalledObject è utile in tutti quei

casi in cui si debbano implementare manualmente

alcuni passaggi tipici di RMI, come il trasferimento

di uno stub da client a server, oppure la serializzazione

dello stesso secondo la semantica di serializzazione

utilizzata in RMI. Molto utile la possibilità di

scaricare, per mezzo del metodo get , la classe

corrispondente all'oggetto remoto, se questa non

è presente in locale al momento della lookup

da parte del client RMI. Questa funzione infatti

permette di risolvere uno dei problemi principali

di RMI, ovvero la necessità di dover installare sul

client il codice ( . class ) corrispondente allo stub

dell'oggetto remoto, prima di effettuare una lookup.