Механізми реалізації розподіленої обробки інформації - студопедія

1. Механізм віддаленого виклику процедур

Синхронний режим комунікацій між двома прикладними модулями (клієнтом і сервером) підтримує специфікація віддаленого виклику процедур (remote procedure call - RPC). Для установки зв'язку, передачі виклику і повернення результату клієнтський і серверний процеси звертаються до спеціальних компонентів - клієнтського та серверного перехідникам, або заглушок (від англ. Stub - заглушка, перехідник). Ці stub-процедури не реалізують ніякої прикладної логіки і призначені тільки для організації взаємодії віддалених (в загальному випадку) прикладних модулів. Кожна функція на сервері, яка може бути викликана віддаленим клієнтом, повинна мати такий процес.

При виклику клієнтом віддаленої процедури спочатку виконується локальний виклик процедури, яка є частиною клієнтського перехідника. Локальний виклик разом з параметрами передається клієнтському переходнику. При цьому за допомогою спеціальної мови опису інтерфейсів (Interface Definition Language - IDL) проводиться визначення інтерфейсу процедури, тобто опис параметрів процедури, що передаються їй до виконання RPC і повертаються після завершення RPC. Потім це опис транслюється і виробляється упаковка даних в формат повідомлення - маршалинга (marshaling). Клієнтський перехідник викликає локальну операційну систему, яка пересилає повідомлення віддаленій операційній системі сервера. Дистанційна операційна система передає повідомлення серверному переходнику, який реалізує серверну частину виклику і складається з програм отримання запиту від клієнта, форматування даних (демаршалінг), виклику реальної процедури (реалізованої на сервері) і повернення результатів клієнту. Клієнт блокується і чекає відповіді, а на сервері запускається серверний перехідник, який перетворює повідомлення в параметри локальної процедури. Сервер бачить виклик як пряме звернення до його локальної процедурі з потрібними параметрами, виконує виклик і передає результати серверного переходнику. Серверний перехідник форматує результати роботи процедури в повідомлення для клієнта і викликає локальну операційну систему сервера. Операційна система сервера пересилає повідомлення операційній системі клієнта. Клієнт виводиться зі стану очікування, його операційна система приймає повідомлення і направляє його клієнтського переходнику, який витягує результати з повідомлення, передає їх клієнту і повертає клієнту управління.

2. Об'єктно-орієнтований підхід до організації розподіленої обробки інформації

Об'єктно-орієнтований підхід сприяє значному вдосконаленню механізмів організації розподіленої обробки інформації. Найважливішим властивістю об'єктів (object) є те, що вони дозволяють приховати своє внутрішню будову за допомогою наявності чітко визначеного інтерфейсу. Тому при заміні або зміні об'єктів інтерфейс може залишатися незміненим. Внаслідок цього можливо відносно легке поширення і застосування принципів RPC до віддалених об'єктів.

Об'єкти інкапсулюють дані, звані станом (state), і операції над цими даними, звані методами (method). Для доступу або маніпулювання станом об'єкта потрібно використовувати методи, звернення до яких здійснюється через інтерфейси. Об'єкт може реалізовувати безліч інтерфейсів, а для цього опису інтерфейсу може існувати кілька об'єктів, що надають його реалізацію.

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

Клієнт, здійснивши зв'язок з об'єктом, може через заступника об'єкта звернутися до методів об'єкта. Таким чином при об'єктно-орієнтованому підході до розподіленої обробки інформації реалізується механізм так званого віддаленого звернення до методів (Remote Method Invocation - RMI).

Звернення до методу може бути статичним (інтерфейси відомі при розробці) або динамічним (параметри збираються перед зверненням до методу).

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

3 Розподілена обробка інформації на основі транзакційного взаємодії

Для реалізації транзакційного взаємодії застосовуються монітори обробки транзакцій TPM (Transaction Processing Monitor), або транзакційні монітори, розроблені для забезпечення надійного мультиплексного доступу до великої кількості ресурсів для великої кількості паралельних користувачів. Механізм TPM - найбільш стара технологія реалізації розподілених систем, яка з'явилася в 1970-х роках в середовищі великих універсальних обчислювальних машин для виконання банківських, страхових та інших висококрітічних обчислень.

Транзакційні монітори представляють одну з найскладніших і багатофункціональних технологій в світі проміжного програмного забезпечення. Вони призначені для автоматизованої підтримки додатків, оформлених у вигляді послідовності транзакцій. Кожна транзакція є кінцевий блок звернень до ресурсу (найчастіше - до бази даних) і деяких дій над ним. Коректне виконання транзакції має гарантувати виконання чотирьох умов - так званих властивостей ACID (Atomicity, Consistency, Isolation, Durability):

* Atomicity (атомарность) - операції транзакції утворюють нероздільний, атомарний блок ( «unit of work» - «одиниця роботи») з певним початком і кінцем. Цей блок або виконується від початку до кінця, або не виконується взагалі. Якщо в процесі виконання транзакції стався збій, відбувається відкат до вихідного стану;

* Consistency (узгодженість) - по завершенні транзакції всі задіяні ресурси знаходяться в узгодженому стані;

* Isolation (ізольованість) - одночасний доступ транзакцій різних додатків до ресурсів координується таким чином, щоб ці транзакції не впливали один на одного;

* Durability (довготривалість) - все модифікації ресурсів в процесі виконання транзакції будуть довготривалими.

Функціональність транзакційних моніторів достатня для розробки, виконання, управління і супроводу транзакційних інформаційних розподілених систем. Ця функціональність включає в себе мову IDL, іменування, безпеку і аутентифікацію, компілятори перехідників, підтримку роботи з транзакційними викликами (транзакційні дужки, зворотні виклики), ведення журнальних записів, відновлення, блокування, управління процесами і пріоритетами, балансування навантаження, реплікацію, управління ресурсами .

Архітектура транзакційних моніторів включає клієнтський інтерфейсний компонент і підтримку прямого доступу через термінал. Програмний потік виконує процедури, написані на мові даного монітора, які містять операції над іменованими логічними ресурсами. Маршрутизатор зіставляє операції і виклики, які можуть ставитися до ресурсів (наприклад, бази даних) або локальним службам самого монітора. До складу маршрутизатора входить спеціалізована база даних, яка містить визначення відповідностей між іменами логічних ресурсів і фізичними пристроями. При зміні системи адміністратор виправляє це відповідність: клієнтську програму модифікувати не потрібно - клієнт знає тільки логічні імена. Взаємодія з ресурсами здійснюється через менеджера взаємодії (наприклад, систему повідомлень, що забезпечує відкат і гарантію доставки). Різнорідність ресурсів, пов'язаних з монітором, приховують оболонки. Виконання транзакції проводить менеджер транзакцій, виконуючий протокол 2РС і гарантує транзакційні властивості процедур, виконуваних транзакційних монітором.

Так, консорціумом OMG була розроблена специфікація об'єктного сервера транзакцій OTS (Object Transaction Server), мета якої - уніфікувати об'єднану функціональність моніторів транзакцій і брокерів об'єктних запитів. Це розширення CORBA знайшло своє відображення в специфікації JTS для Java (Java Transaction Service - служба транзакцій Java).

4. Розподілена обробка інформації на основі технологій обміну повідомленнями

1) з передачею повідомлень,

2) c чергами повідомлень,

Системи з передачею повідомлень (Message Passing - MP) забезпечують безпосередню взаємодію додатків один з одним шляхом відправки та отримання повідомлення. Для цього між програмними модулями встановлюється логічне з'єднання. Звідси випливає, що дане рішення не підходить для слабо пов'язаних програм, які працюють в незалежному тимчасовому режимі, наприклад, додатків, певні компоненти яких обслуговують мобільних користувачів. Обмін повідомленнями може відбуватися в синхронному і асинхронному режимі. Крім кошти безпосередніх комунікацій, системи цього типу можуть забезпечувати додаткові служби проміжного шару, наприклад, службу каталогів.

Черги повідомлень можуть бути довготривалими (persistent) чи ні. В останньому випадку, якщо відбудеться збій в роботі менеджера черг, то повідомлення в черзі будуть втрачені. Якщо підтримується довгострокова чергу, повідомлення будуть відновлені після перезапуску менеджера. Цей варіант безумовно є кращим для більшості відповідальних додатків. Ще однією відмінною рисою проміжних систем на основі черг повідомлень є забезпечення одного з трьох рівнів «якості обслуговування»:

* Надійна доставка повідомлень (reliable message delivery) - система гарантує, що в процесі обміну повідомленнями жоден мережевий пакет не буде втрачено;

* Застрахована доставка повідомлень (assured message delivery) - кожне повідомлення доставляється тільки один раз.

Проміжні системи на базі черг повідомлень можуть підтримувати обробку транзакцій, розбиваючи великі синхронні транзакції, які модифікують кілька розподілених, різнорідних баз даних, на менші асинхронні транзакції, які взаємодіють один з одним за допомогою черг. Таким чином МОМ-системи можуть використовуватися як більш продуктивний асинхронний комунікаційний рівень для моніторів обробки транзакцій ТРM. Черги повідомлень представляють собою потужний, гнучкий і в той же час простий механізм межпрограммного взаємодії. По суті, цей механізм близький до іншої парадигми розробки додатків - створення програм, керованих подіями. Подія однієї програми (представлене повідомленням) викликає певну дію в іншому. І така модель найбільш близька до реального взаємодії процесів в бізнесі реальних компаній.

Представниками програмних продуктів, побудованих на базі черг повідомлень, є системи MQSeries компанії IBM, MSMQ (Microsoft Message Queuing Server) компанії Microsoft, MessageQ компанії BEA, dbQ компанії Sybase.

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

Технологічною основою для всіх середовищ обміну повідомленнями нового покоління стала специфікація JMS (Java Message Service - служба повідомлень Java), в деталях визначає, як взаємодіють клієнти і сервери в середовищі асинхронних повідомлень. До достоїнств JMS відноситься те, що вона відповідає сучасним уявленням про взаємодію додатків і не вимагає спеціальних знань і доступна для будь-якого програміста, що працює на мові Java. Цими якостями вона помітно відрізняється від інструментарію MQSeries, де необхідна спеціальна підготовка. Ще один стимул для народження нового покоління MOM - поява розширюваної мови розмітки даних XML (eXtensible Markup Language - «розширювана мова розмітки») для Internet-додатків, що дозволяє одним додаткам «розуміти» інші.

5. Розподілена обробка інформації на основі моделей узгодження

Основним підходом, який використовується в розподілених системах на основі моделей узгодження, є відділення власне обчислювальних процесів від механізмів їх узгодження. Якщо розглядати розподілену систему як набір процесів (можливо, багатопоточних), то обчислювальна частина розподіленої системи утворена групою процесів, кожен з яких здійснює конкретні обчислювальні операції, причому ці операції в принципі можуть виконуватися незалежно від інших процесів. У цій моделі согласующая частина розподіленої системи підтримує всі взаємодія між процесами і організовує їх взаємну кооперацію. Вона утворює той «клей», який пов'язує воєдино діяльність, виконувану різними процесами. У розподілених системах узгодження основна увага приділяється погодженням процесів.

У тому випадку, якщо процеси мають связностью посилань і часу, узгодження здійснюється безпосередньо і має назву прямого узгодження (direct coordination). Можливості підключення посилань зазвичай має вигляд явної ідентифікації співрозмовника в процесі взаємодії. Так, наприклад, процес може взаємодіяти з іншим процесом тільки в тому випадку, якщо він знає ідентифікатор процесу, з яким хоче обмінятися інформацією. Тимчасова зв'язність означає, що обидва взаємодіють один з одним процесу активні одночасно. Така зв'язність має місце при нерезидентної зв'язку на основі повідомлень.

Прикладом системи узгодження є система Jini ( «Джин») компанії Sun Microsystems. Віднесення Jini до систем узгодження засноване в першу чергу на те, що ця система здатна підтримувати генеративную зв'язок за допомогою Linda-подібної служби під назвою JavaSpace. Однак існує безліч служб і засобів, які роблять Jini більше, ніж просто системою узгодження.

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

Архітектура системи Jini може бути представлена ​​у вигляді трьох рівнів. Найнижчий рівень утворює інфраструктура. На цьому рівні розташовуються базові механізми Jini, в тому числі і ті, які підтримують взаємодію за допомогою звернень RMI мови Java. Служби надаються як звичайними процесами, так і пристроями, на яких програмне забезпечення Jini (в тому числі і віртуальна машина Java) виконуватися не може. Тому що реєструють і пошукові служби також відносяться до інфраструктури Jini. Другий рівень утворюють кошти загального призначення, які доповнюють базову інфраструктуру і можуть бути використані для більш ефективної реалізації служб. У число цих засобів входять підсистеми подій і повідомлень, засоби оренди ресурсів і опису стандартних інтерфейсів транзакцій. Самий верхній рівень складається з клієнтів і служб. На противагу іншим двом рівням Jini не визначає склад цього рівня однозначним чином. Актуальна реалізація системи підтримує кілька служб верхнього рівня, серед яких сервер JavaSpace і менеджер транзакцій, який реалізує інтерфейси транзакцій Jini. Програмами верхнього рівня, крім того, нерідко дозволяється безпосередньо використовувати механізми інфраструктури Jini.

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