[Java]Pattern Proxy-Skeleton

[neidus]

Se qualcuno conosce questo tipo di pattern, può vedere se sbaglio qualcosa nell'implementazione?

Protocollo usato TCP, quindi classi Socket e ServerSocket

Classe Client= genera i thread che devono inviare richieste al Server

Classe ClientThread= nel costruttore crea la Socket client, ridefinisce il metodo run(), selezionando quanto deve essere mandato come richiesta, crea un'istanza del Proxy lato client, e su di esso invoca un metodo dell'interfaccia base.

Classe Proxy Client= implementa i metodi che sono definiti nell'interfaccia, inviando per ogni tipo di metodo quello che serve, tramite i canali di I/O, al Server e leggendo quanto gli viene inviato dal server

Classe Skeleton= gestisce la connessione lato server, implementa l'interfaccia definita e lascia indefiniti i metodi della stessa, legge quanto scritto dal client sul canale, e invoca un thread skeleton, passano socket di connessione, riferimento all'interfaccia e dati del pacchetto dopo aver fatto unmarshalling.

Classe SkeletonThread= costruttore, dove legge i dati passati dallo Skeleton, crea un canale di scrittura su Stream per scrivere i dati ottenuti dall'invocazione del metodo richiesto, per restituirli al client.

Classe ServerReale= implementa effettivamente cosa devono fare i metodi definiti nell'interfaccia creata.

Classe Server= istanzia un obj serverReale su cui richiama l'esecuzione dello skeleton

Grazie mille.

[valia]

Originariamente inviato da neidus
Se qualcuno conosce questo tipo di pattern, può vedere se sbaglio qualcosa nell'implementazione?

Protocollo usato TCP, quindi classi Socket e ServerSocket

Classe Client= genera i thread che devono inviare richieste al Server

Classe ClientThread= nel costruttore crea la Socket client, ridefinisce il metodo run(), selezionando quanto deve essere mandato come richiesta, crea un'istanza del Proxy lato client, e su di esso invoca un metodo dell'interfaccia base.

Classe Proxy Client= implementa i metodi che sono definiti nell'interfaccia, inviando per ogni tipo di metodo quello che serve, tramite i canali di I/O, al Server e leggendo quanto gli viene inviato dal server

In realtà tu hai una interfaccia e dichiari che il tuo client è in grado di soddisfarla, in questo proxy non ne vedo.
sai già a priori quali sono le richieste (quindi automatiche) o devi gestirle? In genere è un client che fa una richiesta al thread, quasi sempre il client (per quanto riguarda il lato richiesta) è mono-thread.
Dimentichi che il client si rivolge da una interfaccia chiedendo un servizio, mettere qui l'interfaccia e i thread è una forzatura che non c'entra molto con l'applicazione del pattern.

Originariamente inviato da neidus
Classe Skeleton= gestisce la connessione lato server, implementa l'interfaccia definita e lascia indefiniti i metodi della stessa, legge quanto scritto dal client sul canale, e invoca un thread skeleton, passano socket di connessione, riferimento all'interfaccia e dati del pacchetto dopo aver fatto unmarshalling.

Classe SkeletonThread= costruttore, dove legge i dati passati dallo Skeleton, crea un canale di scrittura su Stream per scrivere i dati ottenuti dall'invocazione del metodo richiesto, per restituirli al client.

vorrei capire tu cosa intendi per "gestisce la connessione lato server".
Quello che tu definisci "skeleton" in realtà non è altro che la tua interfaccia (anche se ovviamente on instanzi nessuna interfaccia).
Vedila così, quando fai una connessione ad un server, ti connetti a qualcuno che dichiara di essere in grado di fare qualcosa. Se ti risponde il proxy o il server reale a te no importa.

Originariamente inviato da neidus
Classe ServerReale= implementa effettivamente cosa devono fare i metodi definiti nell'interfaccia creata.

Classe Server= istanzia un obj serverReale su cui richiama l'esecuzione dello skeleton

Grazie mille.

Per capire una applciazione di questo puoi provare a capire bene come funziona RMI che in pratica applica questo pattern.
E' sempre ben chiaro avere lo schema del pattern a vista

proxy

con relativi esempi

[neidus]

no vabbhè questo non è il pattern proxy semplice....si chiama appunto Pattern Proxy-Skeleton,

porta praticamente alla definizione di un Interfaccia (non l'avevo scritta perchè ne parlavo nelle varie iterazioni)

il client genera T Thread, che richiamano metodi sull'istanza di un Proxy, che a sua volta gestisce la connessione lato client (creazione socket client, marshalling e unmarshalling dei dati)....e sul proxy richiama il servizio definito nell'interfaccia (Proxy implements InterfacciaServizio)

Poi lo Skeleton praticamente è il duale del Proxy, solo che è lui che richiama un Thread per servire la richiesta del client.....il thread generato effettua l'operazione richiesta e restituisce una risposta.

ServerReale implementa i metodi definiti nell'interfaccia....che vengono poi richiamati nel thread.

Server crea un'istanza di ServerReale e invoca su di esso il metodo di esecuzione dello Skeleton.

Scrivo questo, perchè oggi l'ho rivisto e l'ho capito meglio.....praticamente sposta la comunicazione Client Server a livello di Proxy-Skeleton....non saranno + i Thread generati o le stesse classi main a gestire la connessione ma viene tutto spostato sui proxy lato cliente e lato servente.

[valia]

guarda io con te davvero non capisco a cosa ti riferisci.
Il pattern skeleton non esiste!!!
Poi fai un giro di pattern per definire una Interfaccia? Interfaccia per chi? Il client o il server?
Se è per il client, non serve perché già la definisce il proxy, quindi questo giro in più al client non serve.
Se è per il server, a cosa serve dire che il server soddisfa una interfaccia in più?

Perché il client ha bisogno di T thread per fare una richiesta? Si mettono T thread al client quando devi fare stress test, non è la normalità.
Guarda RMI e lo skeleton non è altro un oggetto a cui puoi fare richieste e a cui registri un servizio, sarà lo skeleton a rigirarle al servizio.
ma la richiesta del client è fatta in modo del tutto trasparente, chiede solo un servizio.

la comunicazione client/server avviene SEMPRE tra client e server, il client NON ha cognizione del proxy. tra PROXY e SERVER instauri una NUOVA comunicazione client/server.

Tu cliente devi gestire la comunicazione col client, sia questo proxy o server tu non lo sai.
Non è che usare un proxy ti toglie l'onere della gestione della comunicazione.

Poi prova a spiegare in italiano comprensibile quello che devi fare, fai riferimento a testi perché giuro io non capisco quello che tu vuoi dire. Da alcune frasi mi rendo conto che confondi un po' di concetti

[neidus]

non capisci perchè non conosci questo pattern semplice....non dire a me che mi confondo...perchè ripeto...non conosci il pattern....sò cos'è un pattern Proxy...se volevo sapere quello avrei scritto Pattern Proxy...non il Proxy-Skeleton

http://www.federica.unina.it/ingegne...roxy-skeleton/

ecco un riferimento x te...x farti capire cos'è

[neidus]

e comunque italiano lo parlo bene....

genera T thread, per generare T richieste....da dover gestire in mutua esclusione...!!!

[valia]

Originariamente inviato da neidus
non capisci perchè non conosci questo pattern semplice....non dire a me che mi confondo...perchè ripeto...non conosci il pattern....sò cos'è un pattern Proxy...se volevo sapere quello avrei scritto Pattern Proxy...non il Proxy-Skeleton

http://www.federica.unina.it/ingegne...roxy-skeleton/

ecco un riferimento x te...x farti capire cos'è

Guarda, per non saper né leggere né scrivere una ricerca su google per proxy skeleton java mica torna qualcosa di utile...vai a capire che lo usano nella tua uni per riferirsi ad un qualcosa di molto simile alla struttura RMI di java!!

dalle tue spiegazioni (e non è la prima volta) non si capisce COSA vuoi dire e la terminologia che usi a volte è imprecisa.

Se chiedi aiuto devi spiegare in dettaglio: sai spiegarmi l'utilità di questo pattern?
Sai spiegarmi a cosa serve e uno schema UML di quello che vuoi fare?
Quando saprai usare i termini tecnici per spiegare questo allora ne riparliamo.

Torni a quello che dico io, la normale implementazione di un client è mono-thread, usi il multi-threading per generare stress test. Ma quello a cui si chiede di rispondere e di gestire la mutua esclusione è il server, non il client.
Di applicazioni client/server ne faccio e di stress test ne ho scritti, ma visto che il client ha tutto quello che gli serve per eseguire senza intralciarsi con altri (spero che tu lo abbia scritto bene), non vedo in cosa dovrebbe interagire con altri.

Molto spesso ho un main che non fa altro che passare in multithreading per me è avere un ciclo che istanzia un client e nel suo run chiama il metodo che fa il client la comunicazione, chiamata che non varia se sono in multi/mono thread.

Infine, vuoi creare un altro livello di astrazione, ma stai di fatto applicando il proxy lato server e lato client vai a definire una libreria per la comunicazione, non un vero proxy o uno skeleton nella tua accezione.
lato server vai a mascherare la risorsa che esegue la tua richiesta,

Se applichi il proxy anche lato client devi gestire
1. comunicazione tra proxy-server e server
2. comunicazione tra proxy-client e client
3. comunicazione proxy-proxy

chiedendo che il tuo proxy-client fornisca gli stessi servizi del server.
lato client vuoi mascherare la richiesta di esecuzione, stai solo aggiungendo un livello di astrazione nella comunicazione, che potrebbe torna utile qualora la tua lib sia generica o quando vuoi dare implementazioni differenti della stessa richiesta, ma porre la coincidenza con l'interfaccia del server a cosa serve?

La comunicazione continua ad essere sempre tra CLIENT e SERVER, il client l'ha delegata alla sua lib, il SERVER è mascherato dal proxy.

mi dici il reale vantaggio di questo giro?

[neidus]

Da quanto ho capito, dovrebbe migliorare la portabilità del codice....sò solo che all'uni lo chiedono...ed è alla base degli esami....praticamente è quello che ho scritto all'inizio....proxy lato server e proxy lato client, solo che il lato server lo chiamavo Skeleton.

+ che stress test, è per sapere se riesce a gestire il server (la mutua esclusione ho sempre detto che fosse lui a gestirla...mai espresso il contrario) + richieste...

cmq visto che usi queste cose....ho trovato una traccia che stò cercando d'interpretare....

Client genererà T thread, chiamati Thread_Client, ognuno dei quali allo scadere di un tempo t
(scelto arbitrariamente tra 0.1 e 0.5 secondi) genererà una richiesta, scegliendo in maniera
arbitraria le seguenti quantità:
o Prenotazioni posti su treno (scelto tra 4 e 8);
o Prenotazioni camere in un albergo (scelto tra 1 e 4);
o Prenotazioni posti in un ristorante (scelto tra 4 e 8).
• In seguito, la richiesta è sottomessa all'intermediario per mezzo di un’opportuna socket e si
porrà in attesa della risposta, che sarà stampata a video. Se il numero di richieste generate è pari
a R, il thread termina, altrimenti si pone in attesa di un tempo t per eseguire una nuova richiesta.
• Agenzia è un'applicazione che riceve dai Thread_Client le richieste formulate come una terna
<Posti_Treno, Posti_Albergo, Posti_Ristorante> e le gestisce in parallelo. Inoltre, riceve delle
richieste di sottoscrizione dai tre componenti GestoreTreni, GestoreAlberghi e
GestoreRistoranti. Nello specifico, alla ricezione di ogni sottoscrizione il riferimento alla socket
del sottoscrittore è memorizzato in un apposito array da Agenzia. Tale array è consultato
quando bisogna gestire un’invocazione da parte di un client. Infatti, Agenzia estrae da ogni
invocazione le tre diverse prenotazioni, ognuna delle quali è smistata a un apposito componente
(es. i posti per i treni sono richiesti al GestoreTreni).
• GestoreTreni, GestoreAlberghi and GestoreRistoranti sono applicazioni che si sottoscrivono
all'Agenzia per ricevere le richieste di prenotazione posti. Ogni componente gestisce una
variabile intera che memorizza la quantità disponibile e inizializzata arbitrariamente tra 20 e N.
Le varie richieste smistate dall'Agenzia devono essere gestite da ogni componente in mutua
esclusione: il valore di prenotazione richiesto è confrontato con il valore di quantità disponibile:
o se uguale o inferiore, la variabile è variata e si ritorna un valore di successo;
o se superiore, si ritorna un valore di insuccesso.


Ho pensato Client, genera il thread.....thread comunica con ilserver e invia richiesta...attende risposta.

Server, si mette in fase di accept()

i 3 gestori hofatto 3 classi separate ognuna con un metodo main in cui creo una socket che deve comunicare con il server.....il server passa i parametri di prenotazione ai vari gestori...che sul canale di comunicazione scrivono la risposta in formato String...restituita poi al client come esito, concatenando i 3 risultati.che ne pensi?