Attivazione di oggetti remoti.


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.
 

Post popolari in questo blog

Gli Scozzesi,usanze,costumi e tradizioni.

Com'è fatta un'automobile.

L'igiene dell'apparato scheletrico. Anatomia.