[JAVA]Client che fa da server

[kleo87]

Buongiorno a tutti..spero di essere nella sezione giusta e di aver messo il titolo giusto

Vi illustro subito il mio problema...
Sto progettando un sistema distribuito composto da un clientB e un serverA (per realizzare ciò utilizzo un pattern proxy)...il clientB riceve dal serverA una lista di oggetti che devo utilizzare per dare una conferma ad un'altra classeC... nella mia ignoranza quindi ho supposto che:



ClasseA(Server) ---->ClasseB(Client/Server)----> ClasseC(Client)



E' possibile che la ClasseB sia Client e Server nello stesso momento... facendo quindi parte di due strutture proxy???

Vi prego aiutatemi...e non ridete se ciò che ho pensato è una cavolata

[morskott]

Eh la società moderna, maschi che fanno da femmine, femmine che fanno da maschi, client che fanno da server.... non c'è più religione!!!!

[kleo87]

Esiste la parità di sessi e scusa se non tutti nascono imparati come solo voi uomini siete in grado di fare..

Qualcuno di veramente intelligente e gentile mi può aiutare?

[morskott]

Originariamente inviato da kleo87

Esiste la parità di sessi e scusa se non tutti nascono imparati come solo voi uomini siete in grado di fare..

Qualcuno di veramente intelligente e gentile mi può aiutare?

Adesso ti dirò dall'alto della mia intelligenza qualcosa che sicuramente ti sorprenderà in modi che non puoi nemmeno immaginare, pronto a ricevere l'illuminazione?

Esiste qualcosa chiamata "Ironia" (la definizione te la googli).

Lo so, come rivelazione è sconvolgente, soprattutto detta così tutta d'un botto, ma vedrai che se riuscirai a farla tua ne rimarrai folgorato dalla sua bellezza.

[kleo87]

mmh una persona cerca aiuto e riceve ironia..uauh

[morskott]

Originariamente inviato da kleo87

mmh una persona cerca aiuto e riceve ironia..uauh

....dove andremo a finire......

[PGI-Bis]

Mentre aspettiamo qualcuno di veramente intelligente rispondo io.

Non vedo problemi tecnici o concettuali nel realizzare ciò che hai pensato. I pattern sono fatti apposta per essere combinati. Nel tuo caso combini un proxy con un proxy. Non è una cosa bizzarra. Basti pensare al factory pattern. In Java la classe che produce è a sua volta il prodotto di un factory pattern. Nulla di strano insomma.

[kleo87]

mmh allora ti pongo l'altro problema..posto ke è possibile "unire" due proxy il mio schema ipotetico usando UML sarebbe quello allegato..però mi viene un dubbio..

in classeB io creo un'istanza di interfacciaBstub che invoca a sua volta i metodi tramite socket all'interfacciaBskel; nel frattempo classeB mi istanzierebbe un oggetto interfacciaCskel, che prende la socket e interfacciaCimpl (quella che materialmente esegue i metodi richiesti dalla classeC).

A questo punto l'oggetto interfacciaCskel che ho appena creato lo faccio partire con il metodo run(): se run() è in funzione io nn posso+usare l'oggetto interfacciaBstub poichè il metodo run è iterativo.

Come ovvio a questo?

Forse mi sn spiegata male..spero capirete :P

[PGI-Bis]

Se il servizio del proxy è sincrono non potresti usare la sua interfaccia prima del termine della richiesta a prescindere dal fatto che la richiesta sia espletata tramite un secondo proy o no.

Se il servizio è asincrono l'iteratività di run è irrilevante.

Dallo schema (bskel e cskel sono thread) direi che potremmo essere nel secondo caso.

[kleo87]

Originariamente inviato da PGI-Bis

Dallo schema (bskel e cskel sono thread) direi che potremmo essere nel secondo caso.

si quei due sono thread ma non so dirti se sto facendo un lavoro sincrono o asincrono..ti spiego è la prima volta ke faccio un proxy e non ho idea della differenza..

mmh forse ho capito..la classeC chiede alla classeB una lista, questo metodo viene effettivamente eseguito da interfacciaCimpl, quest'ultima può eseguire il metodo presente in interfacciaBstub che richiede a classeA la lista..

questo è fattibile giusto?se si ho risolto..mi interessa che sta lista passi da interfacciaBimpl a interfacciaBstub a interfacciaCimpl che la passa a classeC. poi una volta che avrò terminato di usare classeB come server (e quindi finito il metodo run()) posso usare classeB per svolgere altri metodi come client con la classeA

[morskott]

Originariamente inviato da PGI-Bis

Mentre aspettiamo qualcuno di veramente intelligente rispondo io.

Non vedo problemi tecnici o concettuali nel realizzare ciò che hai pensato. I pattern sono fatti apposta per essere combinati. Nel tuo caso combini un proxy con un proxy. Non è una cosa bizzarra. Basti pensare al factory pattern. In Java la classe che produce è a sua volta il prodotto di un factory pattern. Nulla di strano insomma.

Mi dispiace, non sei compliant all'elevato standard di intelligenza richiesto in questo 3D, avanti il prossimo

[PGI-Bis]

Il sincrono/asincrono è una questione di concorrenza più che di proxy.

Il fatto che skelB e skelC siano Thread mi fa supporre che siano servizi asincroni.

Asincrono nel senso che il client chiede qualcosa e il server risponde "ok, ti chiamo io quando ho la risposta".

Il server parte e il client continua a fare quello che gli pare. Al limite può anche mettersi in attesa della risposta.

In quest'ottica è indifferente che il metodo che esegue il servizio sia ciclico: il client richiede l'esecuzione e ottiene immediatamente la restituzione del controllo il che gli consente di inoltrare nuove richieste.

Il server poi deciderà come gestire questo accumulo di richieste.

[PGI-Bis]

Originariamente inviato da morskott

Mi dispiace, non sei compliant all'elevato standard di intelligenza richiesto in questo 3D, avanti il prossimo

[morskott]

Tornando seri, mi sa che c'è un po di confusione tra classe che implementa un metodo e thread che esegue quel metodo.
Nel caso sincrono, a grandi linee ma PGI-Bis l'ha spiegato meglio, il thread client chiede qualcosa al thread server, il thread server esegue la sua computazione mentre il thread client sta fermo aspettando e quando ha finito dà il risultato al thread client che riprende la sua computazione, mentre nel caso asincrono il client chiede al server qualcosa e va avanti facendo qualcos'altro, il server computa e, magari tramite una call-back (per esempio quando il client richiede il servizio registra al server un metodo da chiamare quando il server ha finito) dà la risposta al client.

Il server stesso ortogonalmente al discorso sincrono/asincrono può essere multi-thread, nel senso che appena riceve una richiesta fa partire un thread di handling della richiesta stessa e si rimette in ascolto per servire nuove richieste, il metodo di gestione è scritto una volta, ma ci saranno n thread che lo eseguono (con tutti i problemi del caso di sincronizzazione delle risorse condivise).

Comunque, se non sei vincolato da constraint di specifica, mi rivolgerei piu a Java RMI che a socket, molto più pulito e semplice. (ti occupi solo della logica di business dei tuoi oggetti fregandotene dell'aspetto della comunicazione), se vuoi info su Java RMI vedi queste slides.

[kleo87]

allora ora ho capito..deve essere sincrono e multi-thread..cmq sn obbligata ad usare la socket (il docente richiede l'implementazione così) cmq ho risolto il mio dubbio e dovrei essere a posto così..

grazie mille dell'aiuto alla prossima

[morskott]

Per l'handling delle richieste (mo non ho visto l'UML) a grandi linee

Class MiaClasseDiHandling implements Runnable{
//Risorse che il server deve utilizzare per l'handling come membri private di classe, tra cui il socket
private Socket s;

public MiaClassDiHandling(Socjet s,//eventuali parametri di inizializzazione){
//Inizializzazione delle risorse
this.s=s;
}

public void run(){
//metodo per l'handling della richiesta
}
}
public class Server{

//Definizione del server

public void avviaHandlingRichieste() throws Exception{ //vedere meglio l'handling delle eccezioni
ServerSocket ss=new ServerSocket(portaDiAscolto);
while (!devoSpegnereIlServer){
Socket s=ss.accept();
MiaClassDiHandling handler=new MiaClassDiHandling(s, //piu altri eventuali parametri);
Thread t=new Thread(handler);
t.start();
}
ss.close();
}
}