І. Б. Трегубенко Г. Т. Олійник О. М. Панаско Сучасні технології програмування в мережах

І.Б. ТрегубенкоГ.Т. ОлійникО.М. ПанаскоСучасні технології програмування в мережахДля засвоєння студентами базових технологій програмування в мережах у теоретичному аспекті розглядаються питання ієрархічної структури об’єктів, об’єктно-орієнтованих концепцій програмування, роботи з формами та фреймами та ін.Викладені матеріали сприяють набуттю практичних навичок з реалізації мережевих додатків, створених за допомогою мов програмування JavaScript та Java. Для студентів вищих навчальних закладів галузі знань 1701 “Інформаційна безпека”, а також фахівців з інформаційних технологій.Зміст Розділ 1.Базові технології програмування в мережах 6 1.1.Поняття про розподілені інформаційні системи 6 1.2. Архітектура клієнт-сервер 8 1.3. Кластерна технологія 11 1.4. Вимоги до сучасних програмних систем 12 1.5.Контрольні питання 19 Розділ 2. Технології програмування на базі мови JavaScript 21 2.1. Основи мови гіпертекстової розмітки HTML 21 2.2. Поняття про технології JavaScript 31 2.3. Основи об’єктно-орієнтованого програмування в JavaScript 32 2.4.Контрольні питання 45 Розділ 3.Технології програмування мовою Java 47 3.1.Огляд можливостей мови Java 47 3.2.Базові типи даних. Оператори. Управляючі конструкції. 48 3.3. Основні поняття мови Java 57 3.4.Масиви 66 3.5.Обробка виключних ситуацій 74 3.6.Наслідування 76 3.7.Полімофізм і розширюваність 87 3.8.Засоби мережевого програмування Java 94 3.9.Контрольні питання 104 Розділ 4.Навчально-методичні матеріали для ПРАКТИЧНОЇ РЕАЛІЗАЦІЇ 106 4.1.Впровадження об’єктів JavaScript в HTML-документ 106 4.2.Базові конструкції мови Javascript 113 4.3.Структурa об’єктів в Javascript 117 4.4.Вікна та динамічне управління документами 122 4.5.Фрейми та Javascript 127 4.6.Форми в JavaScript 132 4.7.Створення простої програми на мові Java 137 4.8.Основні конструкції мови Java. Типи даних 139 4.9.Введення в класи Java 141 4.10.Класи в Java. Інкапсуляція. Наслідування. Поліморфізм. 145 4.11.Графіка в Java 152 4.12.Розробка і застосування аплетів 159 4.13.Обробка подій 167 4.14.Створення мережевих додатків. Робота з сокетами 183Покажчик ключових термінів і понять 192Література 195 ВступІнформаційні технології є однією зі сфер сучасного життя, що найдинамічніше розвиваються. Потужність сучасних обчислювальних пристроїв, яка постійно підвищується, їх мініатюризація, приводять до того, що вони знаходять все більше застосування в усіх областях людської діяльності. Складно уявити собі сучасне суспільство без глобальної мережі Internet або стільникового зв’язку. Інформаційні системи оточують нас всюди, вони починають використовуватися у все нових областях, стають все більш складними. Деякі системи розвиваються та ускладнюються настільки, що починають носити глобальний характер і від їх правильного та надійного функціонування починає залежати діяльність все більшої кількості користувачів. Через свою «глобальність», яка полягає в територіальному розподіленні, а також через ряд інших причин, такі системи часто мають дуже складну архітектуру, функціонування якої у вигляді набору компонентів виконується на окремих вузлах мережі. Оскільки кількість таких систем постійно зростає, вимоги, що висуваються до них, досить високі. Проектування та розробка таких систем є також складними, як і методи та засоби, які застосовуються при реалізації таких проектів. Тому вочевидь існує потреба в спеціалізованих курсах, до яких, зокрема, відноситься дисципліна «Сучасні технології програмування в мережах», що є центральною в циклі загальних професійно-орієнтованих дисциплін і спрямована на освоєння технологій програмування, зокрема мов, орієнтованих на розробку і застосування мережевих додатків. Вона дає фахівцю з напряму інформаційної безпеки знання мережевої тематики, необхідні йому для розробки і захисту будь-якої інформаційної системи.Дисципліна «Сучасні технології програмування в мережах» є складовою частиною циклу дисциплін з інформаційних технологій, які вивчаються студентами впродовж всього курсу навчання в університеті. Вона забезпечує формування у студентів базових понять і навичок створення в операційному середовищі Windows програмних комплексів, що допускають мережевого використання.^ Розділ 1.Базові технології програмування в мережах 1.1.Поняття про розподілені інформаційні системи На сьогоднішній день особливо актуальними є розподілені інформаційні системи. Це системи, головна ознака яких – наявність кількох центрів оброблення даних, що дає змогу виконувати паралельні обчислення. В загальному випадку вони є взаємозв’язаним набором автономних комп’ютерів, процесів або процесорів. Так як вузлами системи можуть бути процеси, то вони включають в себе і програмні засоби. В більшості випадків розподілена система складається з декількох процесорів, сполучених комутуючою апаратурою. Крім розподілених відомі ще і монолітні системи.Розподілені інформаційні системи – децентралізовані системи, як правило гетерогенні. На противагу ним – монолітні системи працюють на одному пристрої, який не взаємодіє з сервером та іншими пристроями.Розподілені системи виникли три десятиліття тому. При побудові інформаційних систем популярною була модель “хост-комп’ютер + термінали”, що реалізовувалась на базі мейнфреймів (наприклад, IBM-360/370, або їх вітчизняних аналогів ­­– комп’ютерів серії ЄС ЕОМ), або на базі так званих МІНІ-ЕОМ. Характерною особливістю такої системи була повна “неінтелектуальність” терміналів, що використовувались як робочі місця. Їх роботою керував хост-комп’ютер.В нашому університеті така система функціонувала в 80÷90-их роках. На базі двох ЕОМ ЄС-1055 в режимі PRIMUS студентами на персональних терміналах в аудиторіях 210-1 та 214-1 розв’язували свої індивідуальні задачі на різних алгоритмічних мовах (FORTRAN, PL-1, Асемблер). Результати своїх розробок вони друкували на системних алфавітно-цифрових друкуючих пристроях, а графічну інформацію виводили на системний планшетний плотер.Цей підхід мав безперечні на той час переваги. По-перше, користувачі такої системи могли спільно використовувати різні ресурси хост-комп’ютера (оперативну пам’ять, процесор) і досить дорогі для тих часів периферійні пристрої (друкуючі та графічні пристрої, пристрої введення з магнітних стрічок і гнучких дисків, дискові накопичувачі). Програмне забезпечення, яке тоді використовувалось, мало справу тільки з “локальними” ресурсами – з локальною файловою системою, локальною оперативною пам’яттю і т.д. Бурхливе зростання індустрії персональних комп’ютерів, що почалося, спочатку мало що змінило в ідеології побудови програмних систем – як і раніше в більшості своїй програми мали справу з локальними ресурсами. Правда, частина цих ресурсів була вже “псевдолокальною”. Наприклад, файли на мережевому диску, хоч, як і раніше оброблялись безпосередньо самим вузлом, але при цьому він спочатку передавався по мережі. Виявилося, що традиційні підходи не працюють за таких умов. При збільшенні обсягу даних, що переробляються, а також по мірі зростання їхньої вартості, прийшли до висновку, що довіряти їх обробку клієнтським машинам не можна – будь-яка помилка на них (а чим більше клієнтів, тим більше вірогідність помилки) приводить або до втрати цілісності даних, або до їх блокувань в процесі роботи. Це в свою чергу означає зниження загальної продуктивності системи.Наступним ключовим кроком стало розповсюдження ідеології клієнт-серверної обробки. Це були системи, в яких клієнт ніс відповідальність за відображення інтерфейсу користувача і виконання коду додатку, а роль сервера зазвичай доручалася системі управління базами даних (СУБД). Наприклад, замість того, щоб читати файл цілком і обробляти його, машина-клієнт передає машині-серверу запит, де вказує, яким чином файл має бути оброблений. Сервер обробляє запит клієнта і повертає йому результат.З появою і подальшим ускладненням подібних систем особливої актуальності набуло поняття «програмного рівня». Концепція рівнів – одна із загальновживаних моделей, що використовувались розробниками програмного забезпечення для розбиття складних систем на більш прості частини. В архітектурі комп’ютерних систем, наприклад, розрізняють рівні коду на мові програмування, функцій операційної системи, драйверів пристроїв, наборів інструкцій центрального процесора і внутрішньої логіки чіпів. У середовищі мережевої взаємодії протокол FTP працює на основі протоколу TCP, який, в свою чергу, функціонує «поверх» протоколу IP, розташованого «над» протоколом Ethernet.При такому підході виділяють верхній рівень, що описує систему в цілому (внаслідок того, що в ньому ігнорують більшість малозначущих деталей). Під ним розташовується рівень, на якому робиться опис (реалізація) операцій, що використовуються на верхньому рівні і так далі. Таким чином, якщо дивитися знизу вгору, кожен рівень, розміщений нижче, забезпечує функціональність, яку використовує рівень, що розміщений вище.Розбиття системи на рівні надає цілий ряд переваг.окремий рівень можна сприймати як одне ціле;можна вибирати альтернативну реалізацію базових рівнів;залежність між рівнями можна звести до мінімуму;більш нижчий рівень може одночасно служити основою для декількох більш вищих рівнів. Інакше для кожного протоколу високого рівня довелося б створювати власний протокол низького рівня;Проте концепція розбиття на рівні має і певні недоліки. А саме:у випадку модифікації одного рівня часом потрібно внесення каскадних змін в інші;наявність надмірних рівнів знижує продуктивність системи, тому що при переході від одного рівня до іншого представлення моделі піддається відповідним перетворенням.Проте найскладнішим при використанні архітектурних рівнів є визначення вмісту і меж відповідальності кожного рівня.Розповсюдження технології клієнт ­­– сервер допомогло вирішити багато старих проблем, але при цьому створило і багато нових. Однією з основних було і залишається визначення межі між функціональністю клієнта та сервера. На практиці досить часто перенесення частини завдань з клієнта на сервер негативно позначається на загальній продуктивності системи. В той же час, перенесення частини навантаження з сервера до клієнта може привести до втрати централізації.З ростом популярності систем клієнт/сервер набирала силу і технологія об’єктно-орієнтованого програмування, яка пропонувала перейти до системної архітектури з трьома рівнями: рівень представлення відводиться призначеному для користувача інтерфейсу, рівень предметної області призначений для опису основних функцій додатку, необхідних для досягнення поставленої перед ним мети, а третій рівень представляє джерело даних.^ 1.2. Архітектура клієнт-сервер З появою поняття Web актуальними стали системи клієнт/сервер, де в ролі клієнта виступав би web–браузер. Інструментальні засоби конструювання Web–сторінок були у меншій мірі пов’язані з мовою баз даних SQL і тому більш підходили для реалізації третього рівня.В даний час можна вважати, що бум технологій, пов’язаних з клієнт–серверною архітектурою все ще продовжується. Більшість сучасних інформаційних систем виконана за цією технологією. Розподілені системи сьогодні досить широко використовуються, так як їх застосування є більш ефективним, ніж використання монолітних. Наведемо їх переваги.^ Обмін інформацією. Необхідність обміну даними між різними вузлами зросла в шестидесятих, коли більшість основних університетів і компаній почали користуватися своїми власними мейнфреймами. Взаємодія між людьми з різних організацій полегшилася завдяки обміну даними між комп’ютерами цих організацій, і це дало зростання розвитку так званих глобальних мереж (WAN).Комп’ютерна система, сполучена в глобальну мережу, як правило забезпечувалася всім необхідним користувачеві: резервними сховищами даних, дисками, багатьма застосовними програмами та принтерами.Пізніше комп’ютери стали більш компактиними та дешевшими. Сьогодні одна організація в більшості випадків має багато комп’ютерів – часто один комп’ютер на одного працівника (робочу станцію). В цьому випадку також доцільно, щоб комп’ютери були сполучені для електронного обміну інформацією між персоналом фірми.^ Розподілення ресурсів. З приходом більш дешевих комп’ютерів стало можливим забезпечення кожного співробітника організації особистим комп’ютером, але це не завжди можливо або доцільно для інших ресурсів (принтери, резервні сховища, блоки дисків і так далі). У цьому випадку кожен комп’ютер може використовувати спеціалізовані вузли – сервери, які забезпечують його даними і надають доступ до спеціалізованих ресурсів. Мережа, що сполучає комп’ютери в масштабі підприємства називається локальною обчислювальною мережею (LAN).Причини, за якими організація встановлює мережу невеликих комп’ютерів, а не мейнфрейми – зниження вартості і розширюваність. По-перше, менші комп’ютери мають краще співвідношення ціна/продуктивність, ніж більші комп’ютери. По-друге, якщо потужність системи більше не задовільняє потреби, то мережа може бути розширена додаванням інших машин (файлових серверів, принтерів і робочих станцій). Якщо ж потужність монолітної системи стає незадовільною, залишається тільки повна її заміна.^ Велика надійність завдяки реплікації. Розподілені системи мають потенціал надійності більший, ніж монолітні системи завдяки властивості їх часткового виходу з ладу. Це означає, що коли деякі вузли системи видуть з ладу, інші, як і раніше, функціонуватимуть і можуть взяти на себе завдання зіпсованих компонентів. Вихід з ладу монолітного комп’ютера діє на всю систему цілком і приводить до можливості продовжувати обчислення. З цієї причини розподілена архітектура при розробці високонадійних комп’ютерних систем є більш доцільною.Високонадійна система як правило складається з декількох уніпроцесорів, які виконують застосовну програму. Правильне функціонування розподіленої системи за наявності пошкоджених компонент вимагає досить складної алгоритмічної підтримки.^ Велика продуктивність завдяки розпаралелюванню. Наявність багатьох процесорів в розподіленій системі відкриває можливість зниження часу обробки завдяки розділенню роботи серед декількох процесорів.Розподілення для забезпечення паралельного виконання часто застосовується при побудові обчислювальних систем, призначених для вирішення складних обчислювальних завдань. Мета такої розподіленої системи – зменшення часу виконання завдання.^ Велика продуктивність завдяки балансуванню навантаження. Часто мотивом для створення розподіленої системи виступає збільшення загальної пропускної спроможності системи шляхом балансування навантаження складових її вузлів. При цьому підході завдання повністю потрапляє на найменш завантажену частину (вузол) системи. Як приклад можна привести будь-яку з систем пошуку в Internet, в якій запит користувача перенаправляється на найменш завантажений на даний момент веб-сервер.^ Спрощення розробки завдяки спеціалізації. Розробка комп’ютерної системи може бути складною, особливо якщо потрібна значна функціональність. Розробка може бути часто спрощена розбиттям системи на модулі, кожен з яких відповідає за частину функціональності і взаємодіє з іншими модулями.На рівні однієї програми модульність досягається визначенням абстрактних типів даних і процедур для різних завдань. Велика система представляється як набір взаємопов’язаних процесів. Модулі можуть бути виконані в рамках одного комп’ютера. Одночасно доцільно мати локальну мережу з різними типами комп’ютерів: один забезпечений спеціальним устаткуванням для обчислень, інший – графічним устаткуванням, третій – дисками і так далі.Як приклад розподілених систем можна привести систему Інтернет. Із самого початку ця мережа розроблялася як розподілена система, здатна продовжувати функціонування при знищенні частини (можливо навіть великої) її складових (вузлів). В результаті з’явилася технологія об’єднання незалежних мереж за допомогою єдиного комунікаційного протоколу, що дозволяє динамічно перенастроювати маршрути передачі пакетів даних. З одного боку, Інтернет є яскравим прикладом системи, побудованої згідно архітектури P2Р, – всі вузли в ньому незалежні. З іншого боку, якщо піднятися на рівень сервісів, то простежуються приклади практично всіх відомих архітектур. Іншим прикладом розподіленої системи є Інтранет. Під інтранетом зазвичай розуміють мережі, об’єднані за якоюсь ознакою (мережі великого підприємства, наприклад). В інтранеті задіяні вузли, доступ до яких необхідний для його користувачів для здійснення певних потреб. Це вузли, що є серверами друку, баз даних, файл-сервера, пошти, сервера додатків та інше. Створення подібних мереж виникає внаслідок потреби в обміні інформацією та забезпечення сумісного доступу до розподілених ресурсів (принтерів та інших пристроїв, доступ до Інтернет, корпоративних даних та інше).Інтранет часто називають «малим Інтернетом», так як він заснований переважно на тих же технологіях, що і «великий» Інтернет. У той же час йому притамана більша захищеність, яка забезпечується централізованим управлінням.^ 1.3. Кластерна технологія Також прикладом розподілених систем можуть служити кластери. Під кластером як правило розуміють декілька обчислювальних вузлів, об’єднаних за допомогою деякої швидкісної технології передачі даних, що мають спеціальне програмне забезпечення. Комп’ютерні кластери в даний час набули великого поширення. Це пов’язано насамперед з тим, що через постійне зниження вартості на устаткування і появу останнім часом відповідного системного програмного забезпечення технологія створення кластерів стала загальнодоступною.Завдяки застосуванню технології кластеризації можна вирішувати ряд задач. Ось деякі з них.Перша технологія пов’язана з резервуванням деяких критичних сервісів. Для цього застосовуються кластери, налаштовані таким чином, що при виході з ладу одного з вузлів, що входять в кластер, сервіси, які обслуговуються цим вузлом, автоматично завантажуються на вузлі іншого кластера. Такий підхід дозволяє істотно мінімізувати час простою системи. Кластери, побудовані за таким принципом, називаються відмовостійкими. Друга технологія вирішує шляхом кластеризації підвищення продуктивності системи. При такому підході один сервіс запускається на декількох вузлах кластера одночасно (при цьому реалізація може бути різною: або на кожному з вузлів запускається копія сервісу, або сервіс запускається на одному вузлі, а частина його процедур розміщується на інших вузлах, або інше). При цьому кількість одночасно оброблюваних завдань збільшується. Але слід зазначити, що для забезпечення такої можливості сервіс має бути спеціальним чином спроектований. Кластери, завдяки яким вирішуються подібні завдання, називаються високопродуктивними.Як правило, вимоги, що пред’являються кінцевою метою застосування кластерів, настільки різні, що кожен конкретний кластер здатний вирішувати тільки одну з них: або забезпечувати відмовостійкість, або підвищувати продуктивність системи. ^ 1.4. Вимоги до сучасних програмних систем Наведемо деякі вимоги, яким повинні задовільняти сучасні програмні системи, що розробляються. Більша частина з них справедлива не тільки до розподілених систем, а взагалі до всіх систем, що розробляються, у тому числі і монолітних. Проте, якщо «розподіленість» для монолітних застосувань може розглядатися як бажана характеристика, то для розподілених систем вона є обов’язковою.Відкритість. Використання відкритих стандартів поряд з детальною документацією специфікацій та протоколів є важливим моментом при створенні будь-якого програмного продукту. Критичної важливості ці чинники набувають при створенні розподілених систем. На сьогодні поширеною є ситуація, коли додаток повинен функціонувати в гетерогенному середовищі. В цьому випадку особливо важливим є збереження незалежності програмного продукту від рішень, пов’язаних з конкретною платформою (з конкретним постачальником). Використання відкритих стандартів підвищує можливості інтеграції і розвитку програмних систем, а також підвищує вірогідність успішного повторного використання окремих програмних компонент і рішень.Безпека. Це важлива властивість будь-якої програмної системи і розподіленої зокрема. Під безпекою зазвичай розуміють сукупність таких властивостей: конфіденційність (забезпечення захисту від несанкціонованого доступу в систему);цілісність (забезпечення цілісності і збереження даних);доступність (забезпечення захисту при паралельному доступі до ресурсів).Для розподілених систем, в яких часто дані пересилаються по мережі, важливим фактором для забезпечення конфіденційності є здібність шифрування повідомлень, що передаються по мережі.Важливою проблемою при проектуванні розподілених систем є забезпечення якості обслуговування. Під якістю обслуговування розуміють якість угоди по виконанню запитів клієнта. Наприклад, запит повинен оброблятися не пізніше, ніж через 2 секунди після отримання або щось таке інше. Жорстким порушенням якості обслуговування є ситуація відмови в обслуговуванні, яка може виникнути у разі, якщо зловмисник атакує сервер запитами, які той не встигає обробляти. Вирішення цієї проблеми в загальному вигляді може бути дуже складним, проте існують рекомендації, що дозволяють обходити її в більшості випадків. Іншою важливою проблемою безпеки є використання мобільного коду, що прийшов по мережі і виконується локально. Тут рішення полягає у використанні спеціального коду та застосуванні віртуальних машин.Масштабованість. Це – одна з можливих переваг, що отримується при реалізації розподіленої системи. Саме можливих, а не дійсних, так як на практиці цілком вірогідна ситуація, коли архітектура розподіленої системи або не допускає зміни числа її вузлів через територіальні чинники, або через зниження продуктивності системи. Незважаючи на деякі обмеження, створення масштабованих систем є бажаним і в одночас складним. При створенні систем, що масштабуються, необхідно досліджувати їхню продуктивність на всіх етапах проектування та реалізації системи, починаючи від самих перших. Вимога масштабованості має завжди включатися в список формальних вимог до характеристик системи. Необхідно ретельно контролювати витоки ресурсів, досліджувати роботу системи, знаходячи і усуваючи вузькі місця. Існують емпіричні оцінки, того, як добитися масштабованості системи. Проте, є обмеження, які негативно впливають на продуктивність. Це можуть бути жорсткі обмеження середовища (наприклад, пропускна спроможність мережевого інтерфейсу), а деякі ресурси взагалі виключають масштабування.^ Обробка помилок. Розподілені системи використовують певне середовище для комунікацій. Дуже часто в ролі такого середовища виступає мережа. На жаль, в розподілених системах часто виникають помилки, які пов’язані з тим, що, по-перше, сама по собі мережа є достатньо ненадійною, по-друге, тому, що архітектура розподіленої системи набагато складніша, ніж монолітної. У зв’язку з цим програмні засоби повинні виявляти ці помилки. Після виявлення помилки, вона має бути маскована, а система повинна спробувати продовжувати виконання процеса, для чого нерідко потрібно повернутися до стану, що мав місце до виникнення помилки.Паралельність. Написання програм, що працюють в паралельному середовищі, складна задача. Проблеми паралелізму виникають всякий раз, коли декілька процесів або потоків обчислень роблять спроби маніпуляції одними і тими ж елементами даних. Сприйняття безлічі паралельних операцій ускладнене врахуванням всіх можливих сценаріїв розвитку подій, що здатні привести до тих або інших негативних наслідків, вкрай складно. Більше того, паралельні операції важко тестувати. Модель транзакцій дозволяє уникнути деяких труднощів: якщо ви маніпулюєте даними всередині транзакції, можна бути впевненим, що нічого поганого з ними не трапиться. Проте це не означає, що проблемами управління паралельними завданнями можна повністю нехтувати, тому що в багатьох випадках доводиться мати справу з даними, що модифікуються декількома транзакціями. Вищезгадана ситуація отримала назву автономного паралелізму.Втім, труднощі пов’язані не тільки з паралелізмом. Іноді їх вносять керуючі системи. Наприклад, втрачені зміни або ефект неузгодженого читання, який виникає в ситуаціях, коли прочитуються дві начебто коректні порції даних, які, проте, не можуть існувати в один і той же момент часу. Обидві проблеми виражаються у втраті достовірності інформації та некоректній поведінці системи, яких можна було б уникнути, якби два процеси не зверталися до одних і тих же даних одночасно. Основною проблемою будь-якої моделі програмування паралельних операцій є не тільки збереження коректності даних, але і забезпечення максимального ступеня паралелізму.Більшість з цих проблем має відомі розв’язки, так як вони виникли ще на початку розвитку галузі. При написанні розподілених програм необхідно використовувати весь досвід, накопичений у даній області – використання критичних секцій та блокуючих змінних, правильна послідовність накладення блокувань та інше.Прозорість. Під прозорістю розуміють приховування від користувача гетерогенної природи системи та представлення її на верхньому рівні як єдиної системи. Виділяють вісім видів прозорості:прозорість доступу: доступ до локальних та віддалених ресурсів за допомогою однакових викликів;прозорість розташування: доступ до ресурсів незалежно від їх фізичного розташування;прозорість паралелізму: можливість декільком процесам паралельно працювати з ресурсами, не впливаючи один на одного;прозорість реплікації: можливість декільком екземплярам одного ресурсу використовуватися без знання фізичних особливостей реплікації;прозорість обробки помилок: захист програмних компонентів від відмов, що мали місце в інших програмних компонентах, відновлення після збоїв;прозорість мобільності: можливість перенесення програмного додатку між платформами без його переробки;прозорість продуктивності: можливість конфігурації системи з метою збільшення продуктивності при зміні складу платформи виконання;прозорість масштабованості: можливість збільшення продуктивності без зміни структури програмної системи та алгоритмів, що використовуються.Для розподілених систем найбільш важливими є прозорість доступу та фізичного розташування, оскільки вони мають критичне значення для належного використання розподілених ресурсів.Керованість. Система використовується тільки в тому випадку, якщо вона керована. Для розподіленої системи задача управління може бути досить складною, бо для розподіленого ресурсу не може бути призначено єдиного центру керування. Це зумовлене тим, що відмова керуючого вузла веде за собою зупинку всієї системи. Інша проблема полягає в тому, що існують системи, які нікому не належать. За своєю сутністю вони є сукупністю більш дрібних або приватних систем, наприклад, Internet. А тому задача управління повинна вирішуватися у кожному конкретному випадку відповідним розв’язком. ^ Складність реалізації. Не дивлячись на те, що розподілені системи можуть володіти рядом переваг в порівнянні з монолітними, при їх створенні доводиться мати справу з рядом істотних труднощів. Наведемо деякі з них.^ Залежність від вибраної архітектури. Як і у випадку проектування традиційного програмного додатку, питання вибору структурних рішень (шаблонів), що лежать в його основі є базовим, навіть можна вважати вирішальним. Так компоненти розподіленої системи часто вимушені взаємодіяти по мережі. Це значно уповільнює виконання додатку (майже на порядок) порівняно з монолітними системами, для яких взаємодія полягає у локальних викликах процедур. Внаслідок цього невдало вибрана структура інтерфейсів або компоновка модулів системи може привести до катастрофічних втрат продуктивності. Крім того, через те, що різні модулі системи виконуються на незалежних вузлах і в рамках незалежних процесів, гостріше виявляються проблеми синхронізації доступу до ресурсів, а також всі пов’язані з цим питання, а саме: забезпечення транзакційної обробки, рівні ізоляції транзакцій та інше. ^ Гетерогенне середовище. Як правило різні частини розподіленого програмного комплексу можуть виконуватися на різних вузлах системи. Вони в свою чергу можуть відрізнятися апаратною, мережевою та програмною архітектурою. Це спричиняє серйозні проблеми в програмуванні таких систем. Навіть представлення такого фундаментального поняття як тип даних залежить від мови програмування, від апаратної архітектури і т.п. Якнайкращим виходом з цієї ситуації може вважатися або використання прийнятих і підтримуваних стандартів (протоколу TСР/ІР для мережевої взаємодії або POSIX для системних викликів). Або використання спеціальних проміжних засобів (middleware), що маскують гетерогенність (Java RMI, CORBA.NET та інше). Цікавим вирішенням проблеми гетерогенності є використання віртуальних машин (наприклад, jvm), що здатні виконувати деякий незалежний від застосованої цільової системи код. При цьому можуть бути створені системи, які працюють і взаємодіють на всяких платформах. Поруч з цим вирішується ще ряд серйозних проблем, пов’язаних, наприклад, з безпекою. Але серйозним недоліком такого підходу є те, що при цьому знижується продуктивність за рахунок введення додаткового посередника – віртуальної машини. Проте, провідні фахівці на ринках Sun, IBM і Microsoft в даний час активно працюють в цьому напрямі, а це свідчить про перспективність даного підходу. Альтернативним методом є підхід, при якому всі модулі системи компілюються під платформи, на яких система використовуватиметься. Цей метод на сьогодні є дуже розповсюдженим.^ Складність розгортання. На відміну від монолітного ресурсу, розподілений додаток має бути розділений на модулі розгортання. Це пояснюється тим, що різні частини розподіленого програмного ресурсу виконуватимуться на різних вузлах, які досить часто мають різні характеристики, а саме апаратну, програмну платформу та інше. На кожен вузол має бути коректно інстальований свій модуль. У випадку, коли в процесі роботи системи відбувається міграція програмних компонент між вузлами, необхідно враховувати особливості гетерогенного середовища.^ Складність налагодження. Характерною особливістю розподілених систем є те, що стан, в якому перебуває система, є також «розподіленим». Це обумовлене тим, що для його фіксації необхідно зібрати інформацію з декількох обчислювальних вузлів. Іншою проблемою є відтворюваність результатів виконання, оскільки процеси, які виконуються на різних обчислювальних вузлах, можуть виконуватися з різною швидкістю, а їх треба гармонізувати між собою.^ Шаблони рішень. Все вищезазначене демонструє видиму складність створення розподіленої програмної системи в порівнянні з монолітною. Незважаючи на значні труднощі, що пов’язані з розробкою розподілених систем, такі системи не тільки розробляються, але і досить широко експлуатуються вже досить довго. Це означає, що знайдено підходи щодо виріщення перерахованих вище проблем. Відомо, що при вирішенні всякої складної задачі доцільно ознайомитися з тим, як подібні завдання розв’язувалися раніше.При уважному дослідженні великих розподілених систем виявляється досить багато загального в їх будові. Це дозволяє говорити про наявність різної архітектури побудови розподілених систем, яка по суті і є таким загальним розв’язком (шаблоном). Крім того, розгляд архітектури, в якій виконуються програмні засоби, дозволяє їх класифікувати за цією ознакою. Оскільки з кожною архітектурою пов’язані характерні її особливості, цих рис набувають і програмні комплекси, реалізовані за відповідною архітектурою. Подібна класифікація на практиці виявляється досить корисною при виборі архітектури проектованої системи.Насправді, знаючи вимоги до системи та відмінні риси різної архітектури побудови, можна вибрати серед них найбільш відповідну для кожного конкретного випадку.При початковому моделюванні системи звертають увагу не тільки на розбиття системи на частини (декомпозицію), але і на взаємодію цих частин (модулів), які можливо виконуватимуться на різних вузлах. Вибір архітектури в більшості випадків породжує той або інший спосіб декомпозиції системи, а також в більшості випадків і способи взаємодії її частин. Добре продумана структура системи повинна забезпечувати надійність, керованість, гнучкість і при цьому дозволяти побудувати економічно ефективне рішення.При описі архітектури функції окремих компонент, як правило, не вказують. Важливішими є розміщення компонент (з урахуванням мережевої топології, яка може мати вирішальне значення при виборі тієї або іншої архітектури), способи розподілу та управління даними, розподіл навантаження між компонентами, а також способи взаємодії. Взаємодія компонентів для розподілених систем є ключовим аспектом. Дуже часто саме особливостями взаємодії диктується зрештою вибір архітектури системи. Інколи, якщо мова йде про реальну ситуацію, модулі розподіленої системи зазвичай вимушені взаємодіяти через мережу того або іншого типу. Відомо, що час передачі даних в мережі на декілька порядків більший, ніж час звернення до даних в локальній пам’яті. Тому прагнуть побудувати систему так, щоб мінімізувати кількість та обсяг такої взаємодії, переносять найбільш активно взаємодіючі модулі на вузли, що з’єднані більш швидкісними каналами.Взаємодія передбачає участь двох сторін – “клієнта” та “сервера”. Відповідно, перший модуль буде клієнтом по відношенню до другого. На практиці ролі визначаються тільки на момент конкретної взаємодії. Так до модуля, що є ініціатором запиту (“клієнтом”), водночас може звернутися інший модуль, що змінить його роль з “клієнта” на “сервер”) .Як зазначалося вище, архітектуру можна розуміти як якийсь шаблон, деяку загальну ідею декомпозиції та взаємодії компонентів, яка до цього вже багато раз застосовувалася. Це дозволяє компенсувати зростаючу складність системи.Інший спосіб подолання складності полягає в розбитті системи, що розробляється, на рівні. Ідея полягає в тому, що існує певне коло задач, які виникають перед розробниками постійно. Отже, потрібно створити деякий набір готових програмних рішень, достатньо загальних за своєю сутністю, щоб ними можна було б скористатися при нагоді. При використанні такої методики додаток розглядається як верхній рівень, що використовує функціональність більш нижчого рівня, який часто називають проміжним програмним забезпеченням (middleware).Проміжне програмне забезпечення (Middleware) ОС та апаратне забезпечення – два нижніх рівні часто об’єднуються під загальним терміном платформа.Middleware – програмне забезпечення між платформою та компонентами розподіленого додатка. Цей рівень не є обов’язковим, але його наявність досить часто бажана. Він реалізує задачі приховування (маскування) гетерогенністі платформи та забезпечує зручну модель програмування.Як приклад такого роду програмного забезпечення можна привести такі продукти:Java (Sun) – технологія виконання проміжного байт-кода на віртуальній машині. Байт-код, що одного разу відкомпілювався, може виконуватися на будь-якій платформі, для якої реалізована JVM (Java Virtual Machine), без перекомпіляції;.NET – технологія Microsoft, заснована на виконанні заздалегідь відкомпільованих в проміжний код