Proxy (design pattern)

1. Proxy (design pattern) Bc. Martin Petruňa 23.10.2012 SAI

2. Proxy zo života • Kreditná karta je proxyk nášmu bankovému účtu - našim peniazom. Možno ju použiť ako náhradu peňazí, ak treba, alebo rovno Na ich výber.

3. Známe Proxy z informatiky • Proxy server (web proxy) Účel: • Bezpečnosť klientov. • Auditing a logovanie. • Cachovanie výsledkov a šetrenie prenosovej kaapacity. • Auditing. • Reštrikcia prístupu k vybraným zdrojom.

4. Známe Proxy z informatiky • Reverseproxy Účel: • Zakrýva skutočnú povahu a štruktúru serverov • Balancovanie záťaže. • Miesto realizácie firewallu a SSL šifrovania. • Cachovanie výsledkov a šetrenie prenosovej kaapacity. • Cachovanie a kompresia statického obsahu.

5. Definícia • Úlohou Proxy je kontrolovať a riadiť prístup k objektu. • Vystupuje v úlohe predsunutého objektu. • Radíme ho k štrukturálnym návrhovým vzorom (podľa GoF).

6. Prečo kontrolovať prístup k objektu? • Objekt môže mať obmedzenú politiku prístupu. Preto chcem kontrolovať resp. obmedziť prístup k objektu. Napríklad chcem umožniť prístup len istým rolám v rámci systému. • Prístup k objektu si vyžaduje extra funkcionalitu. Je napríklad požiadavka na synchronizovaný prístup, alebo je nutné prístup realizovať netriviálne z dôvodu externej povahy objektu (po sieti, špeciálny protokol). Prípadne je nutné zabezpečiť rôzne „domáce“ servisy – napr. počítanie referencií. Alebo len chceme pridať ďalšiu funkcionalitu, pridať správanie – napr. logovanie, tranzakčnosť.

7. Prečo nepracovať priamo s objektom? • Objekt môže byť veľký a jeho vytvorenie náročné. Preto chceme oddialiť túto náročnú operáciu, tzv. lazy loading, až do doby, keď bude objekt skutočne použitý. • Objekt môže byť vzdialený. My budeme pracovať s lokálnou proxy (maketou), ktorá sa postará o remote komunikáciu. Môže ísť o objekt, web-servisu, atď. • Chceme mať možnosť zmeniť objekt stojaci za proxy bez toho, aby si to klient všimol. Objekt je bezstavový, a z dôvodu škálovania chceme mať pool objektov a dynamicky ich prideľovať obsluhu volaní od klientov.

8. Schéma Proxy patternu Kód, ktorý vlastní referenciu na Subject (typuProxy). Spoločný interface pre Proxy a realSubject. Alternatívne Proxy oddedí od RealSubject. Proxy objekt riadiaci prístup k RealSubject. Zpravidlanedeleguje volanie vždy, len ak treba. Zastupovaný RealSubject, prístup ku ktorému je transparentný.

9. Sequence diagram Proxy patternu Je očividne jednoduchý a priamočiary.

10. Príklad z knihy DesignPatterns: ElementsofReusableObject-Oriented Software (K.Zhang) Objekt aj proxy implementujú Graphicinterface. Objekt aj proxy implementujú Graphicinterface. Implementácia vykreslenia (ak nemáš, load-ni, každopádne vykresli). Implementácia getExtent() pre potreby formátovania dokumentu.

11. Príklad z knihy Pár poznámok • Moja motivácia je vyhnúť sa nárazovému načítaniu množstva obrázkov pri otvorení dokumentu, ak ani neviem, či ich budem potrebovať. Otvorím 500-stranové .pdf-ko prezriem si zo 5 strán a zavriem. Určite by nebolo ideálne, ak by som z príslušného skladu obrázkov v pdf objekte hneď načítal všetkých 300 obrázkov v dokumente. Dokument môžem naformátovať, na to mi stačia rozmery obrázkov (získam cez getExtent()), ale obrázky si načítam až keď usernascrolluje na príslušnú stranu. • Proxy si samozrejme drží referenciu na príslušný objekt, aby ho mohlo vo vhodnom čase načítať.

12. Rôzne typy Proxy • Remote – reprezentuje externý objekt v našom systéme, rieši komunikáciu s ním – kódvanie požiadaviek, transport, protokoly a podobne. • Virtual– zdržuje vytvorenie drahého objektu, cachuje niektoré údaje za účelom oddialenia tejto konštrukcie, rôzne optimalizuje. Copy-on-write – zdržanie nákladného kopírovania objektu až do momentu, keď sa ide jeho stav meniť (optimalizácia). • Protection – stará sa o autorizáciu prístupu k objektu, prípadne o filtrovanie/obmedzovanie prístupného obsahu a správania. • Smart– napr. smart pointer – počíta referencie a v prípade poklesu na nulu odstráni objekt, a podobné utility servisy. • NewFeature – stará sa o synchronizáciu prístupu k objektu s viacerých vlákien, logovanie, a ďalšie správanie sprevádzajúce prístup k objektu.

13. Nevýhody Proxy (1) • Nemožnosť volať samého seba. Ako príklad vezmime nejaké tranzakčné alebo securityproxy. V tom prípade si musíme stále dávať pozor, že nevoláme priamo samého seba, ale pristupujeme k sebe cez Proxy (inak by sme prišli o príslušné featury, či už tranzakčnosť alebo bezpečnosť). Tým pádom sa aj pomerne jednoduchá trieda môže stať komplexnou. • Nemožnosť porovnávať referencie. Nie je možné porovnávaťreferencie, ani testovať na rovnosť, kedžemôžeme mať dverôzne Proxy objekty referujúce na rovnaký objekt (rovnakáreferencia), ale k tejtoreferenciisapriamo nedostaneme, aby smeju mohli porovnať (dobrý príklad z javy je napr. Hibernate entity proxy).

14. Nevýhody Proxy (2) • Ukrytie životného cyklu a aktuálneho stavu objektu/resource-y pred klientom. Klient sa môže pokúšať pristúpiť k danému objektu, hoci ten môže byť práve nedostupný alebo v nevhodnom stave. V tom prípade buď clientblockne, alebo hodí nejakú výnimku. Tá bude zrejme unchecked (Java), kedže Proxy nemôže meniť interface zastupovaného objektu. Taktiež sa môže zastupovaný objekt nečakane(z pohľadu klienta) zmeniť. (Príklad – JPA provider načíta objekty z DB, niektoré relácie sú lazy, objekty sa oddelia od entity managera, a ak chce potom klient traverznúť reláciu, zistí že tam má null – kedže bez opätovného attach-nutia si entity manager nevie dotiahnuť chýbajúci objekt). • Vytváranie dojmu, že medzi prácou s lokálnym a remote objektom vlastne nie je rozdiel. Je preto nutné si dobře uvedomovať, o akúresourcesa jedná. V prípaderemotevstupujú do hry faktory jako doba odozvy, podružný spôsobkomunikácie (protokoly), ale aj napríkladdistrubovanétranzakcie(značne odlišné od lokálnych).

15. Proxy v Jave EE • Proxy sú takmer všade, najmä v enterprise Jave. • Java.rmi.* package – obsahujetriedy pre vzdialené volanie objektov, základom je interfaceRemote a sada rôznych výnimiek, ktoré môžu vzniknúť pri tomto spôsobe komunikácie. • Java.lang.reflect.Proxy– ponúka statické metódy na vytváranie dynamických proxy pre triedy a inštancie, zároveň je nadtriedou všetkých týchto proxy. Základom je InvocationHandler, ktorý definuje správanie proxy pri prístupe k objektu. Ukážka vytvorenia dynamickej proxy (v runtime!):

16. Proxy a WS/ RMI(Web Services, RemoteMethodInvocation) • Proxy pattern v RMI umožňuje reprezentovať objekt bežiaci na inej JVM ako lokálny objekt. • Pri WS umožňuje reprezentovať vzdialené servisy ako lokálne objekty. Pri štandardnom JAX-WS je proces zhruba takýto: Klient disponuje WSDL súborom príslušného servisu, v rámci vývojového lifecycle v istej fáze sparsuje dané WSDL-ko a vygeneruje umelé triedy (wsimporttool), ktorých objekty (stub) budú reprezentovať tento servis. Infraštruktúru na generovanie a komunikáciu s web servisom už zabezpečí framework a java. So servisom sa potom pracuje ako s obyčajným lokálnym objektom. Druhou možnosťou je pomocou JAX –WS API a pokročilého použitia XML –RPC a XML konštruktov dynamicky za behu generovať príslušné objekty reprezentujúce daný servis na lokálnej JVM.

17. Proxy a EJB(EnterpriseJavaBeans) • Využitie Proxy v EJB spočíva v možnosti pridať a spravovať vzdialené volania beanov (v klastri, na inej JVM), a pridať kontajnerové servisy ako je bezpečnosť, tranzakčnosť a podobne. • V prípade statelessbeanov taktiež pooling. • EJB kontajner na základe analýzy beanbundlov vygeneruje automaticky proxy triedy pre všetky beany (local i remote). • Možno rozlišovať medzi client-sideproxies a server side-proxies. Rozdiel spočíva v tom, kto cez dané proxy k objektu pristupuje. Pri client-side je to náš kód (naša aplikácia), pri server-side zasa kód kontajnera, keď zabezpečuje lifecycle a servisy.

18. Proxy a CDI (commondependencyinjection) –Weld(referenčná implementácia CDI) • V prípade CDI sú všetky Injection pointy (miesta, kde CDI doplní príslušné objekty/závislosti) reprezentované pomocou Proxy, a všetky tieto objekty sú spravované CDI, tj. Sú dynamicky produkované, odstraňované, dekorované, volania metód sú interceptované, a je zabezpečené, že za proxy sa skrýva správna beana vzhľadom na typ kontextu a ďalšie nastavenia. • Proxies sú taktiež thread-safe. Beany sú konštruované až v čase skutočného volania metódy na nich. • Vo welde je logika dekorátorovvykonávana práve medzi volaním proxy a volaním skutočného objektu. • Samozrejme, nie všetky beany môžu byť proxiované(pre podrobnosti pozri špecifikáciu).

19. Ďakujem za pozornosť!