Documente Academic
Documente Profesional
Documente Cultură
Capitolul 6
2013
Invocare la distanta
Protocoale cerere raspuns (engl. request reply protocols)
Ofera suport de nivel coborat pentru emiterea unor cereri de executie a operatiilor la distanta Ofera suport direct metodelor RPC si RMI Se bazeaza pe serializarea datelor (engl. marshalling) si referinte la distanta (engl. remote references)
Apel de procedura la distanta (engl. remote procedure call RPC), aparut in 1984
Permite unui program client sa apeleze in mod transparent o procedura ce ruleaza intr-un proces server, aflat posibil pe un calculator diferit de calculatorul clientului.
Un format extern comun de reprezentare a datelor primitive si a structurilor de date compuse se numeste reprezentare externa a datelor. Procesul de conversie a unei structuri de date intr-o forma convenabila pentru transmisie = impachetare (engl. marshalling). Procesul de reconstruire a unei structuri de date dintr-un format folosit pentru transmisie = despachetare (engl. unmarshalling).
2013
Reprezentari externe
Formatul de serializare al obiectelor Java.
Specific limbajului Java Fiecare obiect este serializat astfel incat sa poata fi refacut la destinatie Serializarea contine si informatie despre clasa obiectului
XML
continut Schema
Referinte la distanta I
Cand un client invoca o metoda a unui obiect aflat la distanta OD (engl. remote object) se va trimite un mesaj de invocare catre procesul server care gazduieste obiectul. Acest mesaj trebuie sa specifice obiectul referit. Referinta unui obiect la distanta (engl. remote object reference) ROD = identificator al unui obiect care este valid intr-un SD. In cadrul oricarui mesaj de invocare a unui OD se transmite un ROD. ROD trebuie generate astfel incat sa se asigure unicitatea lor in timp si spatiu. Deoarece pot exista mai multe procese ce gazduiesc OD, trebuie ca ROD sa fie unice pe multimea tuturor acestor procese. Chiar si dupa ce un OD a fost sters, ROD corespunzatoare nu se va refolosi pentru a se evita referirea unor obiecte eronate.
2013
Referinte la distanta II
O reprezentare a unui ROD poate contine: adresa de IP a calculatorului, numarul portului, data crearii OD, un numar local al obiectului ce este incrementat automat de procesul care a creat OD. La aceasta se poate adauga o descriere a interfetei OD. In cazul in care un OD exista numai in cadrul procesului care l-a creat si va dispare odata cu distrugerea acestuia, o ROD va putea fi folosita pe post de adresa a obiectului. In cazul in care obiectele pot fi relocate, o ROD nu se va putea utiliza pe post de adresa a obiectului, pentru aceasta existand tehnici speciale.
32 bits IP address 32 bits port number 32 bits time 32 bits object number interface of remote object 2013
Protocol cerere-raspuns
Client Server Request message (wait) Reply message (continuation) getRequest select object execute method sendReply
doOperation
Este de obicei o operatie sincrona, clientul blocandu-se pana la primirea raspunsului serverului. Este fiabila raspunsul serverului este in acelasi timp si o confirmare de primire a cererii de catre client. Pentru mesaje scurte este convenabil de implementat in UDP.
2013
se utilizeaza de clienti pentru a invoca o operatie la distanta. argumentele sale specifica un OD si metoda care se va invoca, impreuna cu eventualele argumente. Rezultatul executiei acestei metode este primirea unui raspuns. Clientul va impacheta datele inainte de transmisie si le va despacheta dupa receptie.
public byte[] getRequest()
Identificatori de mesaje
Orice schema de gestiune a mesajelor intr-un SD ce presupune asigurarea fiabilitatii si/sau implementarea unui protocol cerere-raspuns cere ca fiecarui mesaj sa i se aloce un identificator unic. Un identificator de mesaj are doua parti:
requestId ce se genereaza prin incrementare de catre expeditor. Se impune ca ciclul de viata al mesajului sa fie mai mic decat timpul in care generatorul revine la 0. Identificatorul procesului expeditor: adresa de IP si numar port. Se poate determina dintr-un pachet UDP
Daca requestId se reprezinta pe n biti atunci valoarea sa maxima este 2n-1. Dupa depasirea valorii maxime, valorile se reiau prin incrementare de la 0. Se impune ca timpul in care se epuizeaza toate valorile posibile sa fie mult mai mare decat durata medie de viata a mesajului in sistem. 2013
Modelul de eroare al protocolului cerere-raspuns Daca cele 3 primitive doOperation, getRequest si sendReply sunt implementate peste datagrame UDP atunci ele vor suferi problemele UDP:
i) erori de omisiune; ii) nu se garanteaza livrarea mesajelor in ordinea expedierii.
In plus protocolul poate suferi de erori ale proceselor. Sa presupunem ca acestea sunt erori de oprire (engl.crash).
2013
Timeout Metoda doOperation trebuie sa foloseasca tehnica timeout pentru a trata cazurile de oprire neasteptata a serverului sau de pierdere a mesajelor. In acest caz exista diverse optiuni:
Retur imediat cu indicarea catre client ca operatia a esuat. Eroarea de timeout poate fi cauzata de pierderea mesajelor de cerere sau de raspuns. In acest caz doOperation poate emite cererea in mod repetat pana cand fie primeste un raspuns, fie intarzierea de primire a raspunsului este suficient de mare ca sa existe certitudine ca problema este de la server, nu de la pierderea mesajelor.
2013
Pierderea mesajelor de raspuns Daca un server a trimis deja raspunsul la o cerere pe care o primeste in duplicat, el va trebui sa o reexecute daca nu a stocat rezultatul prelucrarii initiale. O operatie se numeste idempotenta daca executia sa repetata va produce un acelasi rezultat. De exemplu, adaugarea unui element la o multime este o operatie idempotenta, insa adaugarea unui element la o secventa nu este o operatie idempotenta. Un server ale carui operatii sunt toate idempotente nu trebuie sa aiba in vedere masuri speciale pentru evitarea executiei repetate ale aceleeasi operatii.
2013
Istoricul interactiunii
Pentru serverele care necesita retransmisia raspunsului fara a reexecuta operatia trebuie gestionata istoria interactiunii. Se numeste istorie o structura care contine mesajele de raspuns care au fost transmise. O intrare in aceasta structura contine un identificator al cererii, un mesaj de raspuns si identificatorul clientului catre care a fost transmis. Aceasta structura se foloseste pentru a permite serverului sa retransmita mesajele de raspuns la cererile clientilor. Pentru ca structura sa nu devina prea mare serverul trebuie sa poata decide cand anumite raspunsuri nu mai trebuie pastrate in istorie. Deoarece un client face o singura cerere la un moment dat, serverul poate interpreta fiecare cerere drept o confirmare a raspunsului anterior. De aceea istoria poate pastra doar ultimul mesaj de raspuns trimis fiecarui client. Tot sunt insa probleme daca numarul clientilor este mare. Deoarece cand un client se termina el nu va confirma ultimul raspuns primit, acesta va trebui sa fie inlaturat automat din istorie dupa un anumit timp.
2013
2013
Interfete (I)
Limbajele moderne de programare permit organizarea programelor ca multimi de module ce comunica intre ele. Comunicarea se face printr-o interfata pentru fiecare modul in parte. Interfata unui modul specifica metodele si variabilele ce pot fi accesate din alte module. Modulele unui SD pot rula in procese separate. Astfel ca un modul nu va putea accesa variabilele din alt modul. Chiar daca de exemplu se poate specifica accesul la anumite atribute, accesul propriuzis se va face prin medode getter si setter. Tehnicile clasice de transfer a parametrilor (apel prin valoare si apel prin referinta) nu sunt potrivite cand apelantul si apelatul sunt in procese diferite.
2013
Interfete (II)
Specificarea unei proceduri sau metode intr-o interfata a unui modul intrun SD se face prin parametrii de intrare/iesire.
Parametrii de intrare sunt transmisi modulului la distanta prin trimiterea valorilor lor intr-un mesaj de cerere si apoi folosirea lor drept argumente pentru executarea operatiei la server. Parametrii de iesire sunt returnati in mesajul de raspuns si sunt utilizati drept rezultat al apelului sau vor inlocui valorile variabilelor corespunzatoare din mediul apelului. Cand un parametru este atat de intrare cat si de iesire, valoarea corespunzatoare va fi transmisa atat in mesajul de cerere cat si in cel de raspuns.
Deoarece pointerii dintr-un proces nu sunt valizi intr-un alt proces, ei nu se transmit ca argumente si nu se returneaza ca rezultate in apeluri la distanta. In modelul client-server, serverul furnizeaza o interfata pentru servicii IS (engl.service interface). In SD obiectuale, un OD furnizeaza o interfata la distanta ID (engl.remote interface). Intre ele exista diferenta ca metodele dintr-o ID pot transmite obiecte si/sau ROD ca argumente si pot returna obiecte si/sau ROD ca rezultate.
2013
Modelul obiectual I
O aplicatie obiectuala consta dintr-o multime de obiecte ce interactioneaza. Un obiect incapsuleaza date si cod. Vom presupune ca accesul la datele private ale unui obiect se poate face numai prin intermediul metodelor sale. Referinte la obiecte. Obiectele sunt accesate prin referinte. Invocarea metodelor unui obiect se face prin intermediul referintei la obiect. Obiectul a carui metoda a fost invocata se numeste obiect tinta (engl.target) sau receptor (engl.receiver). Referintele pot fi atribuite variabilelor, transmise ca argumente metodelor sau returnate ca rezultate ale metodelor. Interfete. O interfata defineste semnaturile unei multimi de metode. Un obiect furnizeaza o anumita interfata daca clasa sa contine cod ce implementeaza metodele interfetei respective. O clasa poate implementa mai multe interfete. O interfata defineste un tip ce se poate folosi in declaratii de variabile sau parametrii.
2013
Modelul obiectual II
Actiuni. O actiune se initiaza cand un obiect invoca o metoda a altui obiect. Obiectul receptor executa metoda corespunzatoare si eventual intoarce controlul obiectului apelant. O invocare poate avea doua efecte:
schimbarea starii obiectului receptor; crearea de noi obiecte; invocari ulterioare de metode ale altor obiecte.
Exceptii. Exceptiile sunt metode elegante de a trata erorile, fara complicarea codului. Ele separa clar codul de tratare a erorilor de codul pentru o executie normala. Colectarea gunoaielor. Este mecanismul prin care se asigura eliberarea automata a spatiului de memorie ocupat de obiectele care nu mai sunt necesare.
2013
SD obiectuale
Starea unui obiect este multimea valorilor variabilelor membre. In acest fel starea unui program obiectual este partitionata logic intr-o multime de obiecte. Distribuirea fizica a acestor obiecte in procese si/sau calculatoare diferite este o extensie naturala a modelului obiectual. SD obiectuale pot adera la o arhitectura client-server. Obiectele sunt gestionate de servere iar clientii pot invoca metodele acestora folosind RMI. Obiectele din servere pot fi la randul lor clienti ale unor obiecte din alte servere. Obiectele dintr-un SD pot fi replicate pentru cresterea tolerantei la defecte si imbunatatirea performantelor sau pot migra pentru cresterea performantei si a disponibilitatii. Obiectele pot folosi primitive de sincronizare pentru a-si asigura accesul concurent corect la propriile variabile membre. Accesul la obiecte doar prin metode este un prim pas spre independenta de formatul de reprezentare si de caracteristicile fizice ale platformei gazda.
2013
remote invocation
2013
remote interface
2013
Instantierea OD
AD pot contine OD ce dispun de metode speciale gen constructor, pentru instantierea altor OD ce pot fi ulterior invocate prin RMI. Spre exemplu, obiectul L din figura de mai jos contine o metoda pentru crearea de OD. Astfel ca in urma invocarii la distanta de catre obiectele C si K ale metodei constructor din obiectul L vor fi create 2 OD si anume M si N.
2013
Semantica RMI
Am aratat ca implementarea functiei doOperation in protocolul RR se poate face in diverse moduri, asigurandu-se diverse nivele ale garantarii livrarii parametrilor:
Reincercarea de a transmite mesajul de cerere: mesajul de cerere este retransmis pana cand se receptioneaza un raspuns sau se presupune ca serverul s-a oprit. Filtrarea duplicatelor: cand se utilizeaza retransmiterea, cererile duplicate sunt filtrate si eliminate de catre server. Retransmisia rezultatelor: se pastreaza o istorie a mesajelor cu rezultatele, pentru a permite retransmiterea fara reexecutarea operatiilor la server.
Diverse combinatii ale acestor variante conduc la o varietate de semantici posbile pentru fiabilitatea RMI din punctul de vedere al apelantului. Fault tolerance measures Retransmit request message No Yes Yes Duplicate filtering Not applicable No Yes Re-execute procedure or retransmit reply Not applicable Re-execute procedure Retransmit reply Maybe At-least-once At-most-once
2013
Invocation semantics
Daca mesajul de rezultat nu a fost receptionat dupa scurgerea cuantei de timeout si nu exista reincercari, nu exista certitudinea ca metoda s-a executat sau nu. Se poate insa ca metoda sa se fi executat, dar mesajul cu rezultatul sa se fi pierdut. Mai mult, in cazul unui sistem asincron este posibil ca mesajul de raspuns sa soseasca dupa timeout. Aceasta semantica este utila in aplicatiile in care eventualele invocari esuate sunt acceptabile.
2013
Semantica invocarii at-most-once In acest caz apelantul fie primeste un raspuns, in cazul in care apelul s-a executat exact o data, fie o exceptie ce il informeaza ca nu s-a receptionat nici un rezultat. Aceasta semantica se poate realiza prin utilizarea tuturor masurilor de toleranta la defecte. Utilizarea reincercarilor va duce la mascarea erorilor de omisiune a mesajelor de invocare sau de rezultat. Masurile aditionale previn erorile arbitrare asigurandu-se ca pentru fiecare invocare o metoda se va executa cel mult o singura data.
2013
Transparenta RMI
In general, invocarile la distanta sunt similare cu invocarile locale din punct de vedere sintactic. Cu toate acestea, invocarile la distanta sunt mai vulnerabile la erori decat invocarile locale. Indiferent de semantica adoptata, exista intotdeauna posibilitatea sa nu se obtina nici un rezultat si in cazul unei erori sa nu se distinga intre o eroare de retea si o eroare in procesul server. Din acest motiv trebuie ca obiectele care efectueaza invocari la distanta sa poata recupera din eventualele erori. Astfel se apreciaza ca diferentele dintre invocarile locale si invocarile la distanta trebuie sa existe la nivelul interfetelor. Spre exemplu, in Java RMI, OD se disting prin faptul ca implementeaza interfata Remote. Ele pot genera exceptii RemoteException. Implementatorii OD cu interfetele specificate printr-un IDL vor avea in vedere faptul ca aceste obiecte pot fi accesate concurent de clienti multiplii, trebuind sa ia masurile de proiectare corespunzatoare. O alta varianta o reprezinta RMI tranzactional unui apel la distanta is se ataseaza proprietati de tranzactie.
2013
Implementarea RMI
Consta dintr-o multime de obiecte si module ce includ:
Modulul de comunicatie Modulul de gestiune a ROD Software-ul de RMI, ce contine obiectele proxy, skeleton si dispatcher.
2013
Software-ul de RMI I
Este un nivel intermediar intre obiectele aplicatiei si modulele de comunicatie si gestiune ROD. Obiectul proxy sau stub. Rolul unui obiect proxy este de a face invocarea metodelor la distanta transparenta pentru client; ele vor delega invocarea catre OD, ascunzand: referirea OD, impachetarea argumentelor, despachetarea rezultatului si expedierea/receptia mesajelor. Exista cate un obiect proxy pentru fiecare OD referit dintr-un proces client ce detine o ROD. Clasa obiectului proxy implementeaza metodele ID ale OD pe care il reprezinta, dar diferit de OD. Fiecare metoda a obiectului proxy impacheteaza o ROD la obiectul tinta, propriul operationId si argumentele sale intr-un mesaj de cerere trimis catre server. Apoi asteapta un mesaj de raspuns, despacheteaza rezultatul si il intoarce obiectului apelant.
2013
Software-ul de RMI II
Obiectul dispatcher. Un server are cate un obiect dispatcher (dispecer) si un obiect skeleton (schelet) pentru fiecare clasa reprezentand un OD. Obiectul dispecer primeste mesajul de cerere de la modulul de comunicatie si utilizeaza campul operationId pentru a selecta metoda corespunzatoare din obiectul schelet. Obiectele dispecer si schelet utilizeaza acelasi operationId pentru metodele ID. Obiectul skeleton. Obiectul schelet implementeaza metodele din ID. Implementarea este destul de diferita de cea din OD. O metoda a scheletului despacheteaza argumentele metodei din mesajul de cerere si invoca metoda corespunzatoare din OD. Apoi asteapta terminarea invocarii, impacheteaza rezultatul, impreuna cu exceptiile, intr-un mesaj de raspuns catre mesajul de cerere expediat de obiectul proxy.
2013
Activarea OD
Unele aplicatii cer ca informatiile sa supravietuiaca perioade lungi de timp. Nu este insa practic ca obiectele ce gestioneaza aceste informatii sa fie mentinute in cadrul proceselor in executie pentru un timp nelimitat, deoarece ele nu sunt efectiv folosite in tot acest timp. Pentru a se evita pierderea de resurse datorata executiei continue a serverelor ce gazduiesc OD, se poate recurge la pornirea acestor servere ori de cate ori acest lucru este cerut de catre clienti. Procesele care pornesc procese server se numes activatori (engl.activator), de exemplu serviciul Inetd din Linux. Un OD este activ cand este disponibil pentru RMI intr-un proces in executie. Altfel el este pasiv, dar poate fi activat. Un OD pasiv consta din 2 parti: i) implementarea metodelor; ii) starea sa in forma impachetata. Activarea unui OD consta din crearea unui obiect activ din obiectul pasiv asociat prin crearea unei noi instante a clasei si initializarea variabilelor membre din starea salvata. Activarea poate avea loc la cerere, de exemplu cand obiectul este invocat de alt obiect. Un proces activator are urmatoarele responsabilitati: i) inregistrarea obiectelor pasive care sunt disponibile pentru activare. Acest lucru presupune inregistrarea numelor serverelor la URL-urile sau numele fisierelor corespunzatoare obiectelor pasive; ii) pornirea proceselor server si activarea OD din cadrul lor; iii) Monitorizarea locatiilor serverelor pentru OD ce au fost deja activate. In CORBA activatorul se cheama implementation repository. In Java RMI exista cate un activator pentru fiecare calculator server.
2013
Persistenta obiectelor
Un obiect care transcede peste activarile/dezactivarile proceselor server se numeste obiect persistent OP. Un astfel de obiect este in general gestionat de o memorie de OP MOP care stocheaza starea sa in forma impachetata pe disc. O MOP gestioneaza un numar mare de OP. Ele sunt activate in momentul invocarii lor de catre alte obiecte. Activarea este transparenta din punctul de vedere al obiectului apelant. Cand nu mai sunt necesare in memorie, OP sunt pasivizate si salvate in MOP. MOP are nevoie de o strategie pentru pasivizarea OP (de exemplu la sfarsitul unei tranzactii, cand OP au o stare consuistenta, sau la terminarea programului). MOP realizeaza si o optimizare, salvand doar acele obiecte care au fost modificate de la ultima salvare. MOP permit in general organizarea OP sub forma de colectii cu nume interpretabile de un agent uman URL sau cale in sistemul de fisiere. Exista doua abordari pentru a decide daca un obiect este OP sau nu: i) MOP gestioneaza multimea radacinilor colectiilor de obiecte persistente si orice obiect care este accesibil dintr-o astfel de radacina este OP. Aceasta abordare este folosita de Persistent Java. MOP ce folosesc aceasta abordare se bazeaza pe un colector de gunoaie pentru a elimina obiectele care nu mai sunt accesibile dintr-o radacina persistenta; ii) MOP utilizeaza clase speciale pe care se bazeaza persistenta. Un OP apartine unei astfel de subclase. Obiectele care nu mai sunt necesare trebuie sterse explicit (abordare specifica C++).
2013
2013
2013
Serverul inscrie OD in registru si ii asigneaza/leaga (engl.bind) un nume Clientul regaseste un OD in registru dupa nume si determina o ROD Sistemul RMI acceseaza un server Web pentru a descarca definitii de clase de la server la client sau invers, pentru diverse OD, atunci cand este necesar.
2013
Accesul la un OD se face prin intermediul unui reprezentativ local al acestuia numit stub sau proxy. Astfel un client va invoca o metoda asupra obiectului stub, acesta fiind responsabil pentru comunicarea cu serverul si executia metodei asupra OD corespunzator pe server. Un obiect stub corespunzator unui OD implementeaza acelasi set de ID ca si OD. 2013
Compilarea surselor. Disponibilizarea claselor in retea. Se refera la disponibilizarea ID si a claselor ce trebuie descarcate de clienti sau servere. Pornirea aplicatiei. Presupune rularea registrului RMI, a serverelor si a clientilor.
2013
2013
Proiectarea ID a MGC
MGC primeste sarcini de la clienti, le executa si le intoarce rezultatul. ID a MGC defineste o singura metoda pentru trimiterea spre executie a unei sarcini. O sarcina de executie este un tip parametrizat Task<T> unde T este tipul rezultatului sarcinii de calcul.
package compute; import java.rmi.Remote; import java.rmi.RemoteException; public interface Compute extends Remote { <T> T executeTask(Task<T> t) throws RemoteException; }
2013
Transferul parametrilor I
Java RMI foloseste mecanismul de serializare Java pentru transportul obiectelor intre JVM diferite in cazul apelurilor la distanta. Un obiect este considerat serializabil daca implementeaza interfata java.io.Serializable. Astfel, clasele care implementeaza interfata Task vor trebui sa implementeze si interfata java.io.Serializable pentru a putea fi transmise ca parametru metodei executeTask(). Acelasi lucru este valabil si pentru obiectele rezultat (corespunzatoare tipului generic T), deoarece ele sunt intoarse ca rezultat de metoda executeTask(). Orice sarcina ce implementeaza interfata Task poate fi transmisa spre executie catre MGC. O astfel de clasa poate contine si alte date necesare pentru executia sarcinii, cat si alte metode necesare in cadrul executiei. Implementarile unor obiecte Task vor putea fi descarcate de Java RMI in JVM unde ruleaza MGC. In acest fel clientii vor putea defini noi sarcini ce pot fi executate pe calculatorul MGC fara a fi nevoie de codul acestor clase instalat pe acest calculator. Transferul unei sarcini catre MGC se face cu metoda executeTask(), disponibila tuturor clientilor pentru apel la distanta.. 2013
Transferul parametrilor II
Argumentele si valorile returnate ale metodelor la distanta pot fi de urmatoarele tipuri: obiecte locale, OD, tipuri primitive, etc. Obiectele locale trebuie sa fie serializabile. Regulile de transfer sunt urmatoarele:
OD sunt transmise in general prin referinta ROD. Pe partea de client o ROD desemneaza obiectul stub asociat OD respectiv. Obiectele locale sunt transmise prin valoare, folosind serializarea obiectelor. Se copiaza implicit toate campurile, exceptand campurile static si transient.
Transferul unui OD prin ROD inseamna ca orice modificare a starii OD prin invocarea unei metode la distanta se va reflecta in OD. Cand se transmite un OD, numai metodele definite de ID sunt disponibile la receptor. Celelalte metode din implementarea clasei obiectului nu disponibile la receptor. In schimb transferul unui obiect local presupune transferul prin valoare, fiind creata o copie a obiectului la receptor. Astfel ca orice scmibare a obiectul la receptor nu se va reflecta in originalul copiei la expeditor.
2013
Implementarea unei ID
O clasa ce implementeaza una sau mai multe ID-uri trebuie in general sa realizeze urmatoarele:
Sa declare ce ID-uri implementeaza Sa defineasca cate un constructor pentru fiecare OD Sa furnizeze cate o implementare pentru fiecare dintre metodele din ID-urile implementate
Un program server RMI trebuie sa creeze o multime de OD-uri initiale si sa le exporte in cadrul sistemului RMI. Acest lucru inseamna ca ele vor fi disponibile invocarii la distanta. Procedura de initializare - setup poate fi incapsulata intr-una dintre metodele implementare clasei unui OD sau poate fi inclusa intr-o alta clasa. Ea trebuie sa realizeze urmatoarele:
Sa creze si sa instaleze un manager de securitate Sa creeze si sa exporte unul sau mai multe OD-uri Sa inregistreze cel putin un OD in registrul RMI (sau intr-un alt serviciu de nume, cum ar fi un serviciu accesibil prin Java Naming and Direcory Interface JNDI) pentru
2013
Implementarea MGC I
package engine; import import import import import import java.rmi.RemoteException; java.rmi.registry.LocateRegistry; java.rmi.registry.Registry; java.rmi.server.UnicastRemoteObject; compute.Compute; compute.Task;
public class ComputeEngine implements Compute { public ComputeEngine() { super(); } public <T> T executeTask(Task<T> t) { return t.execute(); } ... 2013
Implementarea MGC II
... public static void main(String[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); } try { String name = "Compute"; Compute engine = new ComputeEngine(); Compute stub = (Compute)UnicastRemoteObject.exportObject(engine, 0); Registry registry = LocateRegistry.getRegistry(); registry.rebind(name, stub); System.out.println("ComputeEngine bound"); } catch (Exception e) { System.err.println("ComputeEngine exception:"); e.printStackTrace(); } } } 2013
Pentru aceasta se compileaza sursele celor doua interfete si se construieste bibilioteca JAR.
cd c:\__users\Lucru\workshops\InterfataCompute\src javac compute/*.java jar cvf compute.jar compute/*.class
Rezulta fisierul compute.jar care se distribuie in subdirectoarele lib ale proiectelor RMIClient si RMIServer. Compilarea celor doua proiecte presupune intai adaugarea la fiecare proiect in parte a bibliotecii compute.jar. In versiunile JDK inaintea versiunii 5.0 era nevoie de un pas suplimentar pentru determinarea claselor stub cu compilatorul rmic. Incepand cu versiunea 5.0 acest pas nu mai este necesar.
2013
Manageri de securitate
Ambele aplicatii client si server au instalat cate un manager de securitate. Din acest motiv fiecare trebuie sa specifice cate o politica de securitate descrisa printr-un fisier special. Politica de securitate descrie drepturile de executie pe care le are un anumit in functie de provenienta sa. In aplicatia noastra se dau toate drepturile posibile codului local, si nici o permisiune codului descarcat dintr-o alta sursa. Efectul este ca MGC restictioneaza codul sarcinilor de calcul primite de a putea executa operatii ce ar necesita permisiuni speciale de securitate. Spre exemplu, codul sarcinii Pi nu necesita nici o permisune de securitate speciala pentru a putea fi executat.
grant codeBase "file:C:/__users/Lucru/workshops/RMIServer/bin/" { permission java.security.AllPermission; }; grant codeBase "file:C:/__users/Lucru/workshops/RMIClient/bin/" { permission java.security.AllPermission; };
2013
Pornirea serverului:
java -cp .;../lib/compute.jar -Djava.rmi.server.codebase=file:/C:/__users/Lucru/workshops/RMIServer/lib/compute.jar -Djava.rmi.server.hostname=Toshiba -Djava.security.policy=server.policy engine.ComputeEngine
Proprietatea codebase defineste o sursa sau locatie de unde se pot incarca clase intr-un JVM. Variabile CLASSPATH defineste un codebase local, in sensul ca defineste una sau mai multe cai din sistemul local de fisiere de unde se pot incarca clase. Pornirea clientului:
java -cp .;../lib/compute.jar -Djava.rmi.server.codebase=file:/c:/__users/Lucru/workshops/RMIClient/bin/ -Djava.security.policy=client.policy client.ComputePi Toshiba 45
2013