ЗМІСТ

Вступ 2

Тема 1. Розподілені системи та ресурси 3

1. Розвиток розподілених систем. 4

2. Характеристики розподілених систем. 7

3. Приклади розподілених систем 10

Тема 2. Розподілене ПЗ. 12

1. Особливості реалізації ПЗ для розподілених систем 12

2. Вимоги до розподіленого ПЗ. 14

3. Шаблони рішень для розподіленого ПЗ. 19

Тема 3. Типові архітектури розподіленого ПЗ. 23

1. Архітектура Клієнт-сервер 23

2. Моделі-варіації архітектури "клієнт-сервер". 24

3. Архітектура P2P (Peer to Peer) 29

Тема 4. API java.net 30

1. Основні характеристики взаємодії розподілених додатків. 31

2. Протокол передачі датаграм UDP 33

3. Використання протоколу TCP 39

4. Практиктичне застосування API java.net 48

Тема 5. Технологія Java RMI 72

1. Створення розподіленої системи за допомогою RMI 72

2. Визначення віддаленого інтерфейсу. 74

3. Реалізація віддаленого інтерфейсу. 76

4. Визначення клієнтського додатку. 81

5. Компіляція та виконання сервера і клієнта. 84

6. Використання технології RMI для обміну об’єктами. 88

Вступ

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

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

Тема 1. Розподілені системи та ресурси

1. Розвиток розподілених систем.

2. Характеристики розподілених систем.

3. Приклади розподілених систем.

Слід зазначити, що на розподілені системи і обробку розподіленої інформації спрямована значна увага в останні декілька років, і майже кожен університет пропонує принаймні один курс по розробці розподілених алгоритмів. Існує велике число книг про принципи побудови розподілених систем, підручник, що у тому числі вважається класичним [1].

Далі, використовуючи термін "розподілена система", ми матимемо на увазі взаємозв'язаний набір автономних комп'ютерів, процесів або процесорів. Комп'ютери, процеси або процесори згадуватимуться як вузли розподіленої системи. Будучи визначеними як автономні, вузли мають бути, принаймні, обладнані своїм власним блоком управління. Таким чином, паралельний комп'ютер з одним потоком управління і декількома потоками даних (SIMD ) не підпадає під визначення розподіленої системи. Щоб бути визначеними як взаємозв'язані, вузли повинні мати можливість обмінюватися інформацією.

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

Більше обмежуючі визначення розподілених систем можуть бути також знайдені в літературі. Tanenbaum [1], наприклад, називає систему розподіленою, тільки якщо існують автономні вузли, прозорі для користувачів системи. Розподілена система в цьому сенсі поводиться як віртуальна самостійна комп'ютерна система, але реалізація цієї прозорості вимагає розробки хитромудрих алгоритмів розподіленого управління.

1. Розвиток розподілених систем.

Не слід думати, що розподілені системи ­– винахід останніх років.

Два-три десятиліття тому при побудові інформаційних систем популярною була модель "хост-компьютер + термінали", реалізована на базі мейнфреймів (наприклад, IBM – 360/370 або їх вітчизняних аналогів – комп'ютерів серії ЄС ЕОМ), або на базі так званих міні- ЕОМ (наприклад, PDP – 11, що також мали вітчизняний аналог – СМ-4 ). Характерною особливістю такої системи була повна "неінтелектуальність" терміналів, використовуваних в якості робочих місць, – їх роботою управляв все той же хост-компьютер.

Цей підхід мав безперечні на ті часи достоїнства. В перших, користувачі такої системи могли спільно використовувати різні ресурси хост-компьютера (оперативну пам'ять, процесор) і досить дорогі для тих часів периферійні пристрої (принтери, графічні пристрої, облаштування введення з магнітних стрічок і гнучких дисків, дискові накопичувачі). Задіяне програмне забезпечення у такому разі мало справу тільки з "локальними" ресурсами – з локальною файловою системою, локальною оперативною пам'яттю і так далі

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

Наступним ключовим кроком стало повсюдне поширення ідеології клієнт-серверної обробки. Це були "дво-ролеві" системи: клієнт ніс відповідальність за відображення призначеного для користувача інтерфейсу і виконання коду додатка, а роль сервера зазвичай доручалася СУБД. У застосуванні приміром з файлом перехід до клієнт-серверної архітектури може бути проілюстрований таким чином: замість того, щоб читати файл цілком і обробляти його, машина-клієнт передає машині-серверу запит, в якому вказує, яким чином файл має бути оброблений. Сервер запит клієнта обробляє і повертає йому результат.

З появою і подальшим ускладненням подібних систем очевидну значущість придбало поняття "Програмного шару".

Концепція шарів (рівнів, layers ) – одна із загальновживаних моделей, використовуваних розробниками програмного забезпечення для розподілу складних систем на простіші частини. У архітектурі комп'ютерних систем, наприклад, розрізняють шари коду на мові програмування, функцій операційної системи, драйверів пристроїв, наборів інструкцій центрального процесора і внутрішньої логіки чипів. У середовищі мережевої взаємодії протокол FTP працює на основі протоколу TCP, який, у свою чергу, функціонує "поверх" протоколу IP, розташованого "над" протоколом Ethernet.

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

Розчленовування системи на шари надає цілий ряд переваг.

• Окремий шар можна сприймати як єдине самодостатнє ціле, не особливо піклуючись про наявність інших шарів.

• Можна вибирати альтернативну реалізацію базових шарів.

• Залежність між шарами можна звести до мінімуму.

• Кожен шар є вдалим кандидатом на стандартизацію.

• Створений шар може служити основою для декількох різних шарів вищого рівня. Інакше для кожного протоколу високого рівня довелося б винаходити власний протокол низького рівня.

Схема розшарування має і певні недоліки.

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

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

Проте найважче при використанні архітектурних шарів – це визначення вмісту і меж відповідальності кожного шару.

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

У міру росту популярності систем "Клієнт/сервер" набирала силу і технологія об'єктно-орієнтованого програмування, яка пропонувала перейти до системної архітектури з трьома шарами : шар представлення відводиться призначеному для користувача інтерфейсу, шар предметної області призначений для опису основних функцій додатка, необхідних для досягнення поставленої перед ним мети, а третій шар представляє джерело даних.

З появою Web усім несподівано захотілося мати системи "Клієнт/сервер", де в ролі клієнта виступав би Web-браузер. Інструментальні засоби конструювання Web-сторінок, що з'явилися, були у меншій мірі пов'язані з SQL і тому більше підходили для реалізації третього рівня.

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