Prehľad architektúry RMI

V architektúre distribuovaných aplikácií je vždy potrebná komunikácia medzi dvoma rôznymi aplikáciami. V aplikáciách založených na Java jedna aplikácia komunikuje s inou vzdialenou / inou aplikáciou bežiacou niekde inde pomocou mechanizmu nazývaného architektúra RMI.

RMI znamená Remote Method Invocation. Je to API poskytované Java, ktoré umožňuje objektu, ktorý sídli v jednom JVM (Java Virtual Machine), získať prístup alebo vyvolať objekt bežiaci na inom JVM. Ďalší JVM by mohol byť na rovnakom alebo vzdialenom počítači. Toto je zaujímavá vlastnosť, pretože v aplikáciách v reálnom čase je pre aplikácie Java veľmi ľahké komunikovať priamo medzi sebou bez externého komunikačného mechanizmu. Vždy je tiež potrebná bezpečná komunikácia medzi aplikáciami založená na architektúre distribuovaných aplikácií.

Dizajn RMI

Predtým, ako pôjdeme do podrobnej architektúry, porozumieme základnému návrhu architektúry RMI.

  • RMI API je uvedené v balíku java.rmi. Predstavme si dva termíny pre porozumenie architektúry dizajnu RMI. Prvým je klient; JVM, ktorý bude volať vzdialený objekt a druhým je server; JVM, ktorý obsahuje vzdialený objekt. Klient teda zavolá server, v tomto prípade na objekt, na vyvolanie metódy.
  • Server potom vráti klientovi odkaz na objekt. Úlovok tu predstavuje objekty, tj miestne aj vzdialené sa na serveri objavia ako lokálny objekt. Medzi nimi nebude existovať žiadna diferenciácia. Syntax metód oboch objektov je tiež rovnaká. Preto server JVM funguje ako normálny JVM bez toho, aby vedel o akomkoľvek objekte, či je lokálny alebo vzdialený.
  • Rovnakým objektom môže byť server aj klient. Získa sa odkaz na vzdialené objekty a používa sa, akoby išlo o lokálny objekt. Infraštruktúra RMI je zodpovedná za nájdenie vzdialeného objektu, zachytenie volania metódy a vzdialené spracovanie vzdialenej žiadosti. Klient vyvoláva metódy na objekte až po získaní odkazu na vzdialený objekt.

Architektúra RMI

Nižšie je schéma architektúry RMI jednoduchým spôsobom. Na internete nájdete rôzne formy rovnakej architektúry, ale máme jednoduchú, ktorá ju pomôže lepšie vysvetliť.

Začnime spojením bodiek z hľadiska dizajnu s architektonickým diagramom.

Klientska aplikácia a serverová aplikácia sú príslušné JVM klientskeho stroja a strojového servera. V aplikácii RMI píšeme dva programy; klientsky program, ktorý sa nachádza v klientskom a serverovom programe, ktorý je umiestnený na serverovom stroji.

Vrstva aplikácie:

Táto vrstva je skutočnými systémami, tj klientom a serverom, ktorí sú zapojení do komunikácie. Program java na strane klienta komunikuje s programom java na strane servera.

stub:

Od úvodného návrhu máme klientske objekty; V architektúre RMI sa nazýva Stub. Je to objekt, ktorý sa nachádza na klientskom počítači a slúži ako proxy server pre vzdialený objekt. Je to ako brána pre klientsky program.

Útržok má rovnaké metódy ako vzdialený objekt. Keď klient volá objekt stub, stub postúpi túto požiadavku vzdialenému objektu (Skeleton) cez infraštruktúru RMI, ktorá sa potom vykoná na serveri.

Stub Vykonáva nasledujúce udalosti: -

  1. Iniciuje spojenie so vzdialeným JVM,
  2. Zapisuje a vysiela (maršály) parametre do vzdialeného JVM,
  3. Čaká na výsledok,
  4. Číta vrátený výsledok,
  5. Prijatý výsledok odovzdajte volajúcemu.

skelet:

Objekt servera, ktorý sa nachádza v serverovom stroji, sa nazýva Skeleton. Stub komunikuje so serverovou aplikáciou pomocou sprostredkujúceho objektu Skeleton.

Zodpovednosťou kostrových objektov je poslať parametre na implementáciu metódy a vrátiť návratové hodnoty späť klientovi.

Skeleton Vykonáva nasledujúce udalosti: -

  1. Číta parameter odovzdaný klientom,
  2. Vyvolá metódu na skutočnom vzdialenom objekte,
  3. Odošlite / odovzdajte výsledok volajúcemu.

Vrstva pahýľ / kostra:

  • Vrstva Stub / Skeleton je zodpovedná za zachytávanie hovorov uskutočnených klientom a presmerovanie týchto volaní na vzdialený objekt. Táto vrstva sa tiež nazýva Proxy Layer. Stub a Skeleton sú proxy servery a klienti. Objekty Stub a Skeleton sú ako rozhranie medzi aplikáciou a zvyškom systému RMI.
  • Účelom tejto vrstvy je prenášať údaje do vzdialenej referenčnej vrstvy pomocou serializácie objektov. Tento proces konverzie údajov / objektov do bajtového toku sa nazýva Marshalling a spätný tok sa nazýva Unmarshalling. Zaradenie sa vykonáva pri vyžiadaní objektu zo servera a oddeľovanie sa vykoná, keď sa zo servera získa referencia na dáta / objekt.

Vzdialená referenčná vrstva:

  • Vrstva proxy je pripojená k mechanizmu RMI prostredníctvom vzdialenej referenčnej vrstvy. Táto vrstva je zodpovedná za komunikáciu a prenos objektov medzi klientom a serverom. Sémantika invokácie spojenia RMI je definovaná a podporovaná touto vrstvou.
  • Vzdialená referenčná vrstva je zodpovedná za udržiavanie relácie počas volania metódy. tj Spravuje referencie vykonané klientom na objekt vzdialeného servera. Táto vrstva je zodpovedná aj za manipuláciu s duplikovanými objektmi.

Dopravná vrstva:

Transportná vrstva je zodpovedná za nastavenie komunikácie medzi dvoma strojmi. Táto vrstva používa na pripojenie štandardný protokol TCP / IP. Skutočná preprava údajov sa vykonáva touto vrstvou. Táto vrstva je súčasťou vzdialenej referenčnej vrstvy.

záver

  • Remote Method Invocation (RMI) je veľmi užitočné API poskytované v JAVA, ktoré pomáha pri komunikácii medzi dvoma rôznymi JVM. Umožňuje objektu vyvolať metódu na objekte nachádzajúcom sa v inom adresnom priestore.
  • Poskytuje zabezpečený spôsob vzájomnej komunikácie aplikácií. Túto funkciu dosahuje prostredníctvom konceptov Stub (objekt volajúci klientom) a Skeleton (vzdialený objekt nachádzajúci sa na serveri).
  • RMI sa používa na vytváranie distribuovaných aplikácií. Zachováva druh bezpečnosti. Architektúra RMI minimalizuje zložitosť aplikácie v distribuovanej architektúre.

Odporúčané články

Toto bol sprievodca architektúrou RMI. Tu diskutujeme podrobne RMI design a architektúru s vhodným blokovým diagramom. Viac informácií nájdete aj v ďalších navrhovaných článkoch -

  1. Architektúra dátového skladu
  2. Čo je protokol TCP?
  3. Čo je to stolný softvér?
  4. Interview Otázky CCNA

Kategórie: