Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
піро.doc
Скачиваний:
29
Добавлен:
05.03.2016
Размер:
646.66 Кб
Скачать

31.Архітектура rmi.

1.Rmi (англ. Remote Method Invocation) - програмний інтерфейс виклику видалених методів в мові Java.

Опис роботи

Розподілена об'єктна модель, що специфікує, яким чином проводиться виклик видалених методів, що працюють на іншій віртуальній машині Java.

При доступі до об'єктів на іншому комп'ютері можливо викликати методи цього об'єкту. Необхідно тільки доставити параметри методу на інший комп'ютер, повідомити об'єкт про необхідність виконання методу, а потім передати значення, що назад повертається. Механізм RMI дає можливість організувати виконання всіх цих операцій.

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

При виклику методу видаленого об'єкту насправді викликається звичайний метод мови Java, інкапсульований в спеціальному об'єкті-заглушці (stub), який є представником серверного об'єкту. Заглушка знаходиться на клієнтському комп'ютері, а не на сервері. Вона упаковує параметри видаленого методу в блок байтів. Кожний параметр кодується за допомогою алгоритму, що забезпечує незалежність від апаратури. Наприклад, числа завжди передаються в порядку, при якому спочатку передається старший байт (big-endian). При цьому об'єкти піддаються сериализации. Процес кодування параметрів називається розгортанням параметрів (parameter marshaling). Основна мета розгортання параметрів - перетворення їх у формат, придатний для передачі параметрів від однієї віртуальної машини до іншої.

Метод, що належить заглушці, створює блок, в який входять наступні елементи:

ідентифікатор видаленого об'єкту;

опис методу, що викликається;

розгорнені параметри.

Потім метод заглушки посилає цю інформацію серверу. Далі об'єкт-одержувач виконує для кожного виклику видаленого методу наступні дії:

згортання параметрів;

пошук викликаного об'єкту;

виклик заданого методу;

витягання і розгортання значення або виключення, що згенерувало даним методом, що повертається;

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

Клієнтський об'єкт-заглушка згущає значення або виключення, одержане з серверу, що повертається. Результат згортання стає значенням методу заглушки, що повертається. Якщо видалений метод повертає виключення, то об'єкт-заглушка повторить його в середовищі об'єкту-клієнта.

Для виклику видаленого методу використовується той же синтаксис, що і для звернення до локального методу. Наприклад, щоб викликати метод getQuantity() об'єкту-заглушки сеntralWarehouse центрального сховища даних на видаленому комп'ютері, буде потрібно використовувати приведений нижче код.

Звичайно, інтерфейси є абстракціями і містять тільки перелік методів. Змінні типу interface завжди повинні бути пов'язані з фактичним об'єктом. При виклику видалених об'єктів змінна посилається на об'єкт-заглушку. При цьому клієнтська програма нічого не знає про тип заглушки, а самі заглушки і пов'язані з ними об'єкти створюються автоматично.

При передачі об'єкту іншій програмі (він може бути параметром або значенням видаленого методу, що повертається) потрібен файл класу, відповідний цьому об'єкту. Наприклад, метод, який повертає значення типа Product. При компіляції клієнтської програми повинен бути згенерував файл класу Product.class.

При завантаженні фрагментів коду по мережі завжди виникають сумніви з приводу належного забезпечення безпеки. У зв'язку з цим в додатках з використанням RMI застосовується диспетчер захисту. Він захищає заглушки від проникнення в них вірусів.

32. XML-RPC

XML-RPC (сокр. від англ. Extensible Markup Language Remote Procedure Call - XML-виклик видалених процедур) - стандарт/протокол виклику видалених процедур, заснований на XML, є прародителем SOAP, відрізняється винятковою простотою вживання. XML-RPC, як і будь-який інший інтерфейс RPC, визначає набір стандартних типів даних і команд, які програміст може використовувати для доступу до функціональності іншої програми, що знаходиться на іншому комп'ютері в мережі.

Протокол XML-RPC був спочатку розроблений Дейвом Вінером з компанії «UserLand Software» в співпраці з майкрософтом в 1998 році. Проте корпорація майкрософту незабаром визнала цей протокол дуже спрощеним, і почала розширювати його функціональність. Після декількох циклів по розширенню функціональності, з'явилася система, нині відома як SOAP. Пізніше за майкрософт початку широко рекламувати і упроваджувати SOAP, а початковий XML-RPC був знехтуваний. Але, не дивлячись на відкидання майкрософту, стандарт XML-RPC зачарував багато програмістів своєю надзвичайною простотою і, за рахунок цього, існує до цього дня і навіть поступово набирає популярність.

33. CORBA[1] (сокр. від англ. Common Object Request Broker Architecture загальна архітектура брокера об'єктних запитів) - технологічний стандарт написання розподілених додатків, просувний консорціумом (робочою групою) OMG і відповідна йому інформаційна технологія.

Призначення CORBA

Технологія CORBA створена для підтримки розробки і розгортання складних об'єктно-орієнтованих прикладних систем.

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

Специфікація CORBA наказує об'єднання програмного коду в об'єкт, який повинен містити інформацію про функціональність коду і інтерфейси доступу. Готові об'єкти можуть викликатися з інших програм (або об'єктів специфікації CORBA), розташованих в мережі.

Специфікація CORBA використовує мову опису інтерфейсів (OMG IDL) для визначення інтерфейсів взаємодії об'єктів із зовнішнім світом, вона описує правила відображення з IDL в мову, що використовується розробником CORBA-об'єкту.

Стандартізовани відображення для Ada, З, C++, Lisp, Smalltalk, Java, COBOL, Object Pascal, PL/I і Python. Також існують нестандартні відображення на мови Perl, Visual Basic, Ruby і Tcl, реалізовані засобами ORB, написаними для цих мов.

Об'єкти по значенню

Крім видалених об'єктів в CORBA 3.0 визначено поняття об'єкт по значенню. Код методів таких об'єктів за умовчанням виконується локально. Якщо об'єкт по значенню був одержаний з видаленої сторони, то необхідний код повинен або бути наперед відомий обом сторонам, або бути динамічно завантажений. Щоб це було можливо, запис, що визначає такий об'єкт, містить поле Code Base - список URL, звідки може бути завантажений код.

У об'єкту по значенню можуть також бути і видалені методи, поля, які передаються разом з самим об'єктом. Поля, у свою чергу також можуть бути такими об'єктами, формуючи таким чином списки, дерева або довільні графи. Об'єкти по значенню можуть мати ієрархію класів, включаючи абстрактні і множинне спадкоємство.

Компонентна модель CORBA (CCM)

Компонентна модель CORBA (CCM) - недавнє доповнення до сімейства визначень CORBA. CCM була введена починаючи з CORBA 3.0 і описує стандартний каркас додатку для компонент CORBA. CCM побудовано під сильним впливом Enterprise JavaBeans (EJB) і фактично є його незалежним від мови розширенням. CCM надає абстракцію єств, які можуть надавати і одержувати сервіси через чітко певні іменовані інтерфейси, порти.

Модель CCM надає контейнер компонентів, в якому можуть поставлятися програмні компоненти. Контейнер надає набір служб, які може використовувати компонент. Ці служби включають (але не обмежені) службу повідомлення, авторизації, персистентности і управління транзакціями. Це служби, що часто використовуються розподіленим додатком. Переносячи реалізацію цих сервісів від необхідності реалізації самим додатком у функціональність контейнера додатку, можна значно понизити складність реалізації власне компонентів.