Java rmi

di
DadaLilli
il
8 risposte
D
DadaLilli
Pochi posts
Iscritto da
feb, 2020
Messaggi:
25

Java rmi

Ciao a tutti,
Vorrei chiedere un parere, ho ad esempio una classe "Evento" (con tanto di tipo evento, gravità, descrizione e durata). E' possibile passare con l'rmi un ArrayList<Evento> eventi in modo da poter estrapolare tutti i dati dell'evento ed inserirli in una tabella all'interno di un'interfaccia? Faccio questa domanda perchè mi è stato detto che con l'rmi "è un po' un casino passare gli oggetti perchè si potrebbe avere problemi con il tipo".

ps il contesto è questo: esiste un "sistema centrale" con tutti gli eventi e le previsioni, ed esiste un'applicazione in cui un utente può fare la ricerca di eventi.

8 Risposte

  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Java rmi

    DadaLilli ha scritto:

    E' possibile passare con l'rmi un ArrayList<Evento> eventi in modo da poter estrapolare tutti i dati dell'evento ed inserirli in una tabella all'interno di un'interfaccia? Faccio questa domanda perchè mi è stato detto che con l'rmi "è un po' un casino passare gli oggetti perchè si potrebbe avere problemi con il tipo".
    Certo che è possibile. Bisogna solo prestare un po' di attenzione. Sia client che server devono avere la stessa definizione della classe Evento (banalmente entrambi possono avere lo stesso file Evento.class ... magari messo in un jar "condiviso") e la classe Evento deve essere "serializzabile" secondo il principio della serializzazione degli oggetti di Java. Quindi implementare java.io.Serializable, ecc....
  • D
    DadaLilli
    Pochi posts
    Iscritto da
    feb, 2020
    Messaggi:
    25

    Re: Java rmi

    andbin ha scritto:

    Certo che è possibile. Bisogna solo prestare un po' di attenzione. Sia client che server devono avere la stessa definizione della classe Evento (banalmente entrambi possono avere lo stesso file Evento.class ... magari messo in un jar "condiviso") e la classe Evento deve essere "serializzabile" secondo il principio della serializzazione degli oggetti di Java. Quindi implementare java.io.Serializable, ecc....

    Grazie mille! Se posso chiedere un'altra cosa: ora sto facendo rmi (e non avevo idea di tutto questo) perciò prima aveva definito il server come una classe singleton, è corretto? L'avevo fatto per provare a vedere se il programma funzionava e quindi ogni volta mi doveva chiamare la stessa classe. Mi chiedevo se essendo un server, fosse necessario definire l'unicità.
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Java rmi

    DadaLilli ha scritto:

    Grazie mille! Se posso chiedere un'altra cosa: ora sto facendo rmi (e non avevo idea di tutto questo) perciò prima aveva definito il server come una classe singleton, è corretto? L'avevo fatto per provare a vedere se il programma funzionava e quindi ogni volta mi doveva chiamare la stessa classe. Mi chiedevo se essendo un server, fosse necessario definire l'unicità.
    Quando usi RMI, lato server devi definire una remote interface di cui poi fai una apposita implementazione con una tua classe. La istanza di questa classe è quella che poi passi al UnicastRemoteObject.exportObject() per "esportare" l'oggetto.
    Ma questa tua classe di per sé, NON serve che sia un "singleton" (es. costruttore privato, getInstance() statico, ecc...). Nel senso che questo design non serve/conta per i client. Potrebbe servire solo a te, sul server, se in più parti della applicazione server devi poter accedere a quello stesso oggetto per qualche motivo. Allora sì, il design come "singleton" potrebbe tornare utile. Ma per il resto no.
  • D
    DadaLilli
    Pochi posts
    Iscritto da
    feb, 2020
    Messaggi:
    25

    Re: Java rmi

    andbin ha scritto:

    Quando usi RMI, lato server devi definire una remote interface di cui poi fai una apposita implementazione con una tua classe. La istanza di questa classe è quella che poi passi al UnicastRemoteObject.exportObject() per "esportare" l'oggetto.
    Ma questa tua classe di per sé, NON serve che sia un "singleton" (es. costruttore privato, getInstance() statico, ecc...). Nel senso che questo design non serve/conta per i client. Potrebbe servire solo a te, sul server, se in più parti della applicazione server devi poter accedere a quello stesso oggetto per qualche motivo. Allora sì, il design come "singleton" potrebbe tornare utile. Ma per il resto no.
    Ok grazie, un'altra cosa che non ho ben chiara: in poche parole il mio "progetto" è costituito da un sistema centrale in cui viene gestito il login, la registrazione, le notifiche e la ricerca di eventi secondo dei criteri e un client utente con le interfacce grafiche e un altro client "gestore" che inserisce gli eventi li elimina e li invia al server. Io ho fatto l'interfaccia che estende Remote con tutti i nomi del metodi (che fanno il throw di RemoteException) che vengono implementati nel server e vengono chiamati nel Client. "Fra" Interfacce grafiche e server ho questa classe che fa da tramite, ogni volta che un utente schiaccia ad esempio "cerca evento con caratteristiche xyz" viene chiamato un metodo di questa classe che dovrebbe richiamare il server e restituire la classe Evento. Quello che mi chiedo io è: ma questa classe è quella che dovrebbe fungere da stub e che prima di chiamare i metodi del server deve cercare l'oggetto server e ricevere le risposte? (e quindi deserializzare i risultati)?
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Java rmi

    DadaLilli ha scritto:

    Quello che mi chiedo io è: ma questa classe è quella che dovrebbe fungere da stub e che prima di chiamare i metodi del server deve cercare l'oggetto server e ricevere le risposte? (e quindi deserializzare i risultati)?
    Lo "stub" è l'oggetto che sul CLIENT funge da proxy, ovvero da "intermediario", per invocare tramite networking i metodi remoti sul server.
    Prima di Java 5 era necessario fare uno step di build in più con il tool "rmic" per generare lo stub. A partire da Java 5, NON è più necessario, lo crea automaticamente il runtime Java.

    Nel client, quando fai il "lookup":

    MyRemote remote = (MyRemote) registry.lookup(name);

    MyRemote è (come esempio) la tua Remote interface e l'oggetto che ricevi dal lookup è appunto quello stub ma lo "vedi" solo come tipo della interfaccia. Ed è su questo oggetto che invochi i metodi che sono implementati sul server.
  • D
    DadaLilli
    Pochi posts
    Iscritto da
    feb, 2020
    Messaggi:
    25

    Re: Java rmi

    andbin ha scritto:

    Lo "stub" è l'oggetto che sul CLIENT funge da proxy, ovvero da "intermediario", per invocare tramite networking i metodi remoti sul server.
    Prima di Java 5 era necessario fare uno step di build in più con il tool "rmic" per generare lo stub. A partire da Java 5, NON è più necessario, lo crea automaticamente il runtime Java.

    Nel client, quando fai il "lookup":

    MyRemote remote = (MyRemote) registry.lookup(name);

    MyRemote è (come esempio) la tua Remote interface e l'oggetto che ricevi dal lookup è appunto quello stub ma lo "vedi" solo come tipo della interfaccia. Ed è su questo oggetto che invochi i metodi che sono implementati sul server.
    Ok, per quanto riguarda il passaggio di arrayList di oggetti da Client a Server, lei mi aveva risposto in precedenza che sia client che server devono avere la stessa definizione della classe Evento e che si può risolvere facendo sì che entrambi abbiano lo stesso file Evento.class in un jar "condiviso"e la classe deve essere "serializzabile", posso fare in modo che la deserializzazione avvenga nella stessa classe in cui invoco i metodi implementati sul server?
  • andbin
    andbin
    Super Famoso
    Iscritto da
    ott, 2013
    Messaggi:
    6270

    Re: Java rmi

    DadaLilli ha scritto:

    posso fare in modo che la deserializzazione avvenga nella stessa classe in cui invoco i metodi implementati sul server?
    Scusa ma questa domanda non è molto chiara. Se hai es. un TuoTipo e l'hai definito correttamente per essere "serializzabile" e poi devi es. passare al server un List<TuoTipo>, la serializzazione sul client e poi la de-serializzazione sul server sono trasparenti per te, non devi fare null'altro a riguardo. Sul server ti ritroverai con un oggetto List popolato da oggetti TuoTipo che avranno gli stessi dati di quelli sul client anche se (ovviamente) NON saranno esattamente gli stessi identici oggetti (proprio come identità) che avevi sul client.

    Non so .. forse ho capito male io la domanda ma .. ti è chiaro ora?
  • D
    DadaLilli
    Pochi posts
    Iscritto da
    feb, 2020
    Messaggi:
    25

    Re: Java rmi

    andbin ha scritto:

    Scusa ma questa domanda non è molto chiara. Se hai es. un TuoTipo e l'hai definito correttamente per essere "serializzabile" e poi devi es. passare al server un List<TuoTipo>, la serializzazione sul client e poi la de-serializzazione sul server sono trasparenti per te, non devi fare null'altro a riguardo. Sul server ti ritroverai con un oggetto List popolato da oggetti TuoTipo che avranno gli stessi dati di quelli sul client anche se (ovviamente) NON saranno esattamente gli stessi identici oggetti (proprio come identità) che avevi sul client.

    Non so .. forse ho capito male io la domanda ma .. ti è chiaro ora?
    Sì, è chiarissimo. Grazie mille!
Devi accedere o registrarti per scrivere nel forum
8 risposte