Half Object Plus Protocol (HOPP)
Proprietati
Tip: Structural
Nivel: Componenta
Scop
Ofera o singura entitate care traieste în doua sau mai multe spatii de adrese.
Introducere
O aplicatie distribuita Java foloseste obiecte peste spatii de adrese diferite - mai multe masini virtuale Java (JVM). Pentru tehnologii precum RMI, obiectele la distanta pot apela metode pe 23323y247x obiecte care sunt instantiate în alte JVM, permitând distribuirea starii si comportamentului. Pentru ca aplicatia distribuita sa functioneze, indiferent ce tehnologie se foloseste, obiectele din JVM diferite trebuie sa comunice unul cu altul.
Sa presupunem ca avem doua masini, A si B, si ca în fiecare este în executie o JVM. Presupunem, de asemenea, ca un obiect din JVM (masina A) are nevoie de un stub pentru a apela metodele unui obiect din JVM (masina B). Odata ce obiectul din masina A are acces la stub, A poate apela metodele pe acel stub, care vor fi redirectionate spre obiectul din masina B.
Dezavantajul este ca toate apelurile de metode pe stub vor fi redirectionate prin retea, ceea ce nu este de dorit în toate cazurile. Câteodata se doreste ca stub-ul sa execute local unele dintre metodele apelate, fara a le trimite la obiectul aflat la distanta.
Acesta este un exemplu de obiect care exista în doua sau mai multe spatii de adrese. Proxy-ul (reprezentarea locala a obiectului aflat la distanta) este considerat ca parte a obiectului aflat la distanta. Prin executarea metodelor local si în JVM la distanta, un obiect executa comportamentul sau în mai multe spatii de adrese. Asa se manifesta sablonul HOPP.
Aplicabilitate
sablonul HOPP se foloseste când:
Un obiect trebuie sa existe în doua spatii de adrese diferite si nu poate fi divizat.
O parte a functionalitatii trebuie sa se execute la distanta, iar o alta parte a metodelor trebuie sa se execute local.
Optimizarile, precum caching-ul, sau combinarea mai multor cereri într-o singura tranzactie pe retea, trebuie aplicate într-o maniera transparenta pentru apelator.
Descriere
Aplicatiile distribuite sunt dificil de scris. Una dintre problemele întâlnite este aceea ca o singura entitate (obiect) trebuie sa existe în mai multe spatii de adrese. Aceasta deoarece obiectul are nevoie sa acceseze multiple dispozitive fizice pe masini diferite sau deoarece obiectul nu poate fi divizat într-o maniera logica.
Divizarea unui obiect în doua, si apoi facerea celor doua jumatati sa comunice la distanta se realizeaza prin executarea rmic cu optiunile keep sau -keepgenerated. Prin aceasta, se economiseste codul sursa pentru stub. Pe urma, codul sursa se editeaza astfel ca anumite metode sunt gestionate de stub si nu sunt redirectionate spre obiectul de la distanta. Când se compileaza codul sursa astfel modificat, se va produce o versiune personalizata a stub-ului.
Din pacate, aceasta limiteaza folosirea ulterioara a rmic deoarece ori de câte ori se foloseste rmic pe obiectul la distanta, este nevoie ca sa se editeze manual codul sursa produs.
Solutia este sa se divida obiectul în doua si sa se ofere celor doua jumatati posibilitatea de a comunica. Fiecare jumatate se implementeaza astfel ca sa poata interactiona cu obiectele din spatiul sau de adrese. Protocolul este responsabil de sincronizarea celor doua jumatati si cu transmiterea informatiei între ele.
Acesta este modul de functionare a sablonului HOPP - se creeaza un obiect care implementeaza interfetele la distanta cerute si care contine o referinta la stub-ul original al obiectului de la distanta. Metodele care trebuie sa se comporte normal (adica trebuie redirectionate spre obiectul la distanta) sunt redirectionate spre stub. Metodele care trebuie sa se execute local sunt gestionate de noua clasa.
Numele HOPP provine de la faptul ca clientul obiectului divizat primeste o jumatate de obiect. Acea jumatate contine si protocolul care-i permite sa comunice cu cealalta jumatate, deci per total jumatate de obiect plus protocol (Half-Object Plus Protocol).
Implementare
Diagrama de clase a sablonului HOPP este
prezentata în Figura 1
Figura 1. Diagrama de clase a sablonului HOPP
Pentru implementarea sablonului HOPP este nevoie de urmatoarele:
HOPP - Interfata care defineste metodele disponibile pentru clientul sablonului HOPP. Ambele jumatati ale obiectului HOPP implementeaza aceasta interfata.
LocalHOPP - Clasa care implementeaza interfata HOPP. Unele dintre metode se executa local; celelalte sunt redirectionate spre RemoteObjectProxy
RemoteObjectProxy Clasa care corespunde unui proxy la distanta si redirectioneaza toate cererile spre cealalta jumatate a obiectului, aflat în alt spatiu de adrese. Acest proxy încapsuleaza protocolul care leaga cele doua jumatati de obiect.
RemoteObject Aceasta jumatate a HOPP contine toate metodele care se executa la distanta.
Client - Apeleaza metodele din interfata HOPP. Aceste apeluri de metode sunt transparente pentru client, indiferent daca acesta foloseste un Remote Proxy, un HOPP, sau un obiect local.
Avantaje si dezavantaje
Avantaje:
Avantajul acestui sablon este ca se dispune de un obiect în doua spatii de adrese, fara prea multa încarcatura suplimentara. Pentru clientul care foloseste o parte a HOPP, aceasta este transparent. Clientii nu sunt afectati de faptul ca obiectul exista într-unul sau mai multe spatii de adrese.
Este chiar posibila ascunderea completa a diferentelor, asa încât clientul crede ca foloseste un obiect local, desi parti din el nu sunt locale. si reversul este posibil - se poate face astfel implementarea, încât clientul crede ca foloseste un Remote Proxy, când de fapt foloseste un HOPP care contine un Remote Proxy. Aceasta prezinta avantajul ca unele dintre metodele care erau prevazute sa se execute la distanta se executa acum local.
Un avantaj foarte puternic este acela ca sablonul permite optimizari dedicate. Fiecare jumatate a HOPP poate determina când si cum doreste sa comunice cu cealalta jumatate. Aceste strategii de comunicare pot îmbunatati performanta prin scaderea numarului de apeluri prin retea fara ca sa fie afectat codul client de la oricare dintre capete.
Dezavantaje:
Dezavantajul este ca o parte a functionalitatii trebuie duplicata. Este necesar acest lucru deoarece fiecare jumatate trebuie sa posede suficienta functionalitate pentru a gestiona obiectele locale.
Variatiuni la acest sablon
Fiecare dintre jumatati pastreaza o referinta la cealalta jumatate si îsi trimit mesaje una alteia. În varianta clasica, numai HOPP de la client are o referinta la cealalta jumatate. Prin urmare, numai HOPP de la client poate initia comunicatia cu jumatatea de la distanta prin apelarea unei metode. Jumatatea de la distanta raspunde numai la fiecare apel prin valoarea returnata. Daca este necesar ca ambele jumatati sa initieze comunicatia, fiecare dintre ele trebuie saa aiba o referinta la cealalta jumatate.
Smart HOPP (SHOPP, HOPP destept). În aceasta implementare, partea locala a HOPP îsi poate alege companionul din mai multe strategii de conectare. Aceasta varianta este utila, de exemplu, când aplicatia este distribuita într-o reteaa flexibila, în care intra si ies masini.
Asymmetric HOPP HOPP asimetric. În aceasta versiune a sablonului HOPP, nu este necesar ca ambele jumatati sa implementeze exact aceeasi interfata. Partea aflata la distanta a lui HOPP poate furniza un proxy nou care sa fie folosit de cealalta parte. Acest proxy nou poate contine anumite optimizari, sau chiar poate fi un proxy pentru un alt obiect aflat la distanta.
sabloane înrudite
Mediator - Obiectele care au nevoie de mediere sunt distribuite în spatii de adrese diferite. sablonul Mediator poate folosi sablonul HOPP pentru a simplifica comunicarea.
Proxy, mai exact Remote Proxy - sablonul HOPP foloseste sablonul Proxy pentru comunicarea transparenta dintre cele doua jumatati ale sale.
Exemplu
PIM trebuie sa fie disponibil în multe locuri, însa datele pe care le pastreaza trebuie memorate într-un singur loc. Exemplul de fata foloseste RMI si sablonul HOPP pentru a pastra un calendar personal pe un server, facând disponibila informatia din el la clienti aflati la distanta.
Interfata Calendar defineste toate metodele care vor fi disponibile la distanta. Aceasta interfata extinde interfata java.rmi.Remote si toate metodele sale declanseaza exceptia java.rmi.RemoteException. În cazul de fata, Calendar defineste trei methode: getHost getAppointments si addAppointment
Exemplul 1 Calendar.java
1. import java.rmi.Remote;
2. import java.rmi.RemoteException;
3. import java.util.Date;
4. import java.util.ArrayList;
5. public interface Calendar extends Remote
Interfata Calendar este implementata de doua clase - obiectul RMI la distanta si stub-ul (proxy-ul) sau. Clasa obiectului aflat la distanta, CalendarImpl, furnizeaza implementarile metodelor, pe când stub-ul gestioneaza comunicatia cu obiectul aflat la distanta. Compilatorul Java RMI (rmic) trebuie executat (rulat) pe CalendarImpl pentru a genera câte o clasa stub si skeleton. Clasa skeleton este furnizata pentru compatibilitate cu versiunile anterioare, nefiind necesara începând cu Java 1.2.
Exemplul 2 CalendarImpl.java
1. import java.rmi.Naming;
2. import java.rmi.server.UnicastRemoteObject;
3. import java.io.File;
4. import java.util.Date;
5. import java.util.ArrayList;
6. import java.util.HashMap;
7. public class CalendarImpl implements Calendar
public CalendarImpl(String filename)
try
catch (Exception exc)
}
public String getHost()
public ArrayList getAppointments(Date date)
return returnValue;
}
public void addAppointment(Appointment appointment, Date date)
else
}
Obiectul CalendarImpl trebuie sa foloseasca clasa de sprijin RMI UnicastRemoteObject pentru ca sa poata gestiona cererile de comunicare adresate ei. În acest caz, constructorul clasei CalendarImpl se exporta folosind metoda statica UnicastRemoteObject.exportObject. Obiectul CalendarImpl are nevoie si de o modalitate de publicare a sa pentru lumea exterioara. În RMI, serviciul de nume apeleaza rmiregistry. Acesta trebuie sa fie în executie înainte de crearea obiectului CalendarImpl. Serviciul rmiregistry este ca o carte de telefon, oferind legatura dintre un nume si un obiect. Când obiectul CalendarImpl se înregistreaza în rmiregistry prin metoda rebind, el leaga numele "calendarimp" de stub-ul obiectului de la distanta.
Pentru ca un client sa foloseasca obiectul de la distanta, el trebuie sa consulte în rmiregistry al masinii gazda si sa primeasca stub-ul obiectului la distanta. Stub-ul se poate compoara cu un numar de telefon. Numarul se poate folosi de oriunde, pe orice telefon, si se obtine o conexiune cu cineva care raspunde la numarul de telefon format. În exemplul de fata, clasa CalendarHOPP este pe post de client pentru obiectul CalendarImpl
Exemplul 3 CalendarHOPP.java
1. import java.rmi.Naming;
2. import java.rmi.RemoteException;
3. import java.util.Date;
4. import java.util.ArrayList;
5. public class CalendarHOPP implements Calendar, java.io.Serializable
public CalendarHOPP(String host)
catch (Exception exc)
}
public String getHost()
public ArrayList getAppointments(Date date) throws RemoteException
public void addAppointment(Appointment appointment, Date date)
throws RemoteException
Clasa CalendarHOPP ofera un beneficiu esential în raport cu un client conventional RMI - ea poate executa local ceea ce în mod normal înseamna apeluri de metode la distanta. Aceasta poate aduce un beneficiu substantial din punctul de vedere al încarcarii datorate comunicatiei. sablonul HOPP implementeaza aceeasi interfata la distanta, dar nu se exporta. El pastreaza o referinta la stub si redirectioneaza toate apelurile de metode pe care nu le poate gestiona la stub. El poate implementa acum metodele ce se doreste a fi executate local - în exemplul de fata, metoda getHost. sablonul HOPP se poate înregistra în rmiregistry ca orice stub normal, însa acum el are abilitatea de a executa local unele metode.
|
