Огляд архітектури RMI

У розподіленій архітектурі додатків завжди потрібна комунікація між двома різними додатками. У додатках на базі Java один додаток спілкується з іншим віддаленим / іншим додатком, який працює десь за допомогою механізму, який називається архітектурою RMI.

RMI розшифровується як виклик віддаленого методу. Це API, що надається Java, який дозволяє об'єкту, що знаходиться в одній JVM (Java Virtual Machine), отримати доступ або викликати об'єкт, що працює на іншому JVM. Інший JVM може бути на тій же машині або віддаленій машині. Це цікава функція, оскільки в додатках у режимі реального часу для Java-програм стає дуже просто спілкуватися між собою без будь-якого зовнішнього механізму зв'язку. Крім того, завжди потрібна безпечна комунікація між додатками на основі розподіленої архітектури додатків.

Дизайн RMI

Перш ніж ми перейдемо до детальної архітектури, ми зрозуміємо основний дизайн архітектури RMI.

  • API RMI надається в пакеті java.rmi. Введемо два терміни для розуміння архітектури дизайну RMI. Перший - клієнт; JVM, який буде викликати віддалений об'єкт, а другий - сервер; JVM, який містить віддалений об'єкт. Отже, клієнт викличе сервер, в даному випадку на об'єкт для виклику методу.
  • Потім сервер поверне клієнту посилання на об'єкт. Тут є як об'єкти, тобто локальний, так і віддалений, з'являться як локальний об'єкт на сервері. Розмежування між ними не буде. Синтаксис методів обох об’єктів також однаковий. Тому сервер JVM діє як звичайний JVM, не знаючи жодного об'єкта, локальний він або віддалений.
  • Один і той же об'єкт може бути і сервером, і клієнтом. Отримано посилання на віддалені об’єкти, і воно використовується так, ніби це був локальний об'єкт. Інфраструктура RMI відповідає за пошук віддаленого об'єкта, перехоплення виклику методу та віддалену обробку віддаленого запиту. Клієнт викликає методи на об'єкт лише після отримання посилання на віддалений об'єкт.

RMI Архітектура

Нижче наведена схема архітектури RMI простим способом. В Інтернеті ви знайдете різні форми однієї архітектури, але у нас є проста, яка допоможе пояснити її краще.

Почнемо з з'єднання крапок з точки зору дизайну з діаграмою архітектури.

Клієнтська програма та серверна програма є відповідними спільними версіями клієнтської машини та серверної машини. У програмі RMI ми пишемо дві програми відповідно; клієнтська програма, що знаходиться на клієнтській програмі, і серверна програма, яка знаходиться на серверній машині.

Шар програми:

Цей рівень є власне системами, тобто клієнтом і сервером, які беруть участь у спілкуванні. Програма java на стороні клієнта спілкується з програмою java на стороні сервера.

Заглушка:

З введення дизайну, у нас є об’єкти клієнта; У архітектурі RMI він відомий як Stub. Це об'єкт, який знаходиться на клієнтській машині, і він виступає як проксі для віддаленого об'єкта. Це як шлюз для клієнтської програми.

Заглушка має ті ж методи, що й віддалений об’єкт. Коли клієнт викликає об'єкт заглушки, заглушка передає цей запит віддаленому об'єкту (скелету) через інфраструктуру RMI, яка потім виконується на сервері.

Stub виконує такі події: -

  1. Ініціює з'єднання з віддаленим JVM,
  2. Записує та передає (Маршали) параметри на віддалений JVM,
  3. Чекає результату,
  4. Читає (Скасувати) повернений результат,
  5. Передайте отриманий результат абоненту.

Скелет:

Об'єкт сервера, який знаходиться в серверній машині, відомий як Скелет. Stub спілкується з серверним додатком за допомогою проміжного об'єкта Skeleton.

Відповідальність об'єкта скелета полягає в тому, щоб відправити параметри для реалізації методу і повернути повернені значення назад клієнту.

Скелет виконує такі події: -

  1. Читає параметр, переданий клієнтом,
  2. Викликає метод на фактичний віддалений об'єкт,
  3. Передайте / передайте результат абоненту.

Шар заглушки / скелета:

  • Шар Stub / Skeleton відповідає за перехоплення викликів, здійснених клієнтом, і переадресацію цих викликів на віддалений об'єкт. Цей шар також називають проксі-шаром. Stub і Skeleton - це проксі-сервери для клієнта та сервера. Об'єкти Stub та Skeleton - це як інтерфейс між додатком та рештою системи RMI.
  • Метою цього рівня є передача даних на віддалений контрольний шар за допомогою об’єктної серіалізації. Цей процес перетворення даних / об'єкта в байтовий потік відомий як Маршалінг, а реверс відомий як Беззмістовний. Маршалинг виконується під час запиту об'єкта з сервера, а Демаркація виконується, коли дані / об'єкт посилаються на сервер.

Віддалений контрольний шар:

  • Проксі-шар з'єднується з механізмом RMI через віддалений контрольний шар. Цей рівень відповідає за зв'язок і передачу об'єктів між клієнтом і сервером. Семантика виклику з'єднання RMI визначається і підтримується цим рівнем.
  • Видалений контрольний шар відповідає за підтримку сеансу під час виклику методу. тобто він управляє посиланнями, зробленими клієнтом, на об’єкт віддаленого сервера. Цей шар також відповідає за обробку дублюваних об'єктів.

Транспортний шар:

Транспортний шар відповідає за налаштування зв'язку між двома машинами. Цей рівень використовує стандартний протокол TCP / IP для з'єднання. Фактична транспортування даних здійснюється через цей рівень. Цей шар є частиною віддаленого еталонного шару.

Висновок

  • Віддалений виклик методу (RMI) - це дуже корисний API, що надається в JAVA, який допомагає в спілкуванні між двома різними JVM. Це дозволяє об’єкту викликати метод на об'єкт, що знаходиться в іншому адресному просторі.
  • Це забезпечує безпечний спосіб додатків спілкуватися один з одним. Ця функціональність досягається за допомогою концепцій Stub (клієнт, що викликає об'єкт) та Skeleton (Віддалений об'єкт, що знаходиться на сервері).
  • RMI використовується для побудови розподілених додатків. Він зберігає тип безпеки. Архітектура RMI мінімізує складність програми в розподіленій архітектурі.

Рекомендовані статті

Це був посібник з архітектури RMI. Тут ми детально обговорюємо дизайн та архітектуру RMI за допомогою відповідної блок-схеми. Ви також можете ознайомитися з іншими запропонованими нами статтями, щоб дізнатися більше -

  1. Архітектура сховищ даних
  2. Що таке протокол TCP?
  3. Що таке настільне програмне забезпечення?
  4. Питання для співбесіди CCNA