- •Розподілені системи
- •Історична довідка
- •Базові терміни та визначення
- •Телекомунікаційні мережі як елемент розподілених систем
- •Модель клієнт–сервер
- •1.3. Особливості розподілених систем
- •Переваги розподілених систем
- •Недоліки розподілених систем
- •Класифікація розподілених систем
- •Характеристики розподілених систем
- •Висновки
- •Запитання для самоконтролю
- •Розподілене середовище
- •Концепції апаратних рішень
- •Архітектура багатопроцесорних систем
- •Системи зі спільною пам’яттю
- •Системи з роздільною пам’яттю
- •Топології багатопроцесорних систем
- •Концепції програмних рішень
- •Та засобів проміжного рівня
- •Операційні системи й розподіленість
- •Проміжне середовище
- •2.5. Поняття розподіленого середовища
- •Розподіл прикладних програм за рівнями
- •Варіанти архітектури клієнт–сервер
- •Програмні компоненти розподілених систем
- •Основи мережної взаємодії
- •2.6. Взаємодія компонент розподіленої системи
- •Концепції взаємодії компонент розподіленої системи
- •Обмін повідомленнями
- •Віддалений виклик процедур
- •Використання віддалених об’єктів
- •Розподілені події
- •Розподілені транзакції
- •Безпека в розподілених системах
- •Опис інтерфейсу програмної компоненти
- •Мова і схеми Extensible Markup Language
- •Soap: мова повідомлень розподіленої системи
- •Wsdl: опис інтерфейсу програмної компоненти
- •Базові технології подання інформації в розподілених системах
- •Вимоги до прикладних програм серверної сторони
- •Висновки
- •Запитання для самоконтролю
- •Рівні протоколів
- •Низькорівневі протоколи
- •Транспортні протоколи
- •Протоколи верхнього рівня
- •Віддалений виклик процедур
- •Виклик локальної процедури та повернення результату
- •Звертання до віддалених об’єктів
- •Розподілені об’єкти
- •Прив’язка клієнта до об’єкта
- •Статичне й динамічне віддалене звертання до методів
- •Передача параметрів
- •1.4 Зв’язок на основі потоків даних
- •Підтримка безперервних середовищ
- •Потік даних
- •Синхронізація потоків даних
- •1.5 Протоколи проміжного рівня
- •Протокол soap
- •Сімейство протоколів xmpp
- •Протокол umsp
- •Висновки
- •Запитання для самоконтролю
- •2. Процеси
- •Потоки виконання. Визначення і структура
- •Стан процесів та потоків виконання
- •Реалізація потоків виконання
- •Потоки виконання в нерозподілених системах
- •Потоки виконання в розподілених системах
- •Багатопотокові клієнти
- •Багатопотокові сервери
- •Інтерфейси користувача
- •Клієнтське програмне забезпечення і прозорість розподілу
- •4.6 Сервери
- •Підходи до побудови серверів прикладного програмного забезпечення
- •Сервери об’єктів
- •Частина 2
- •Представлення додатка розподіленної системи
- •Рівнева організація додатку
- •Рівнева організація, застосування, виділення рівнів
- •Використання рівня Сервісів(Services Layer)
- •Дизайн рівневої структури
- •Вибір стратегії розбиття на рівні
- •Визначення наскрізної функціональності
- •Визначення інтерфейсу між рівнями
- •Вибір стратегії реалізації і впровадження
- •Вибір протоколів взаємодії
- •3. Дизайн Рівню Представлення
- •Дизайн рівня представлення включає наступні кроки:
- •Специфічні проблеми дизайну рівня представлення
- •Кешування
- •Комунікації
- •Композиція
- •Управління виключеннями
- •User Experience(Зручність Використання)
- •Інтерфейс користувача
- •Перевірка даних вводу користувача (Validation)
- •Batching(Пакетування)
- •З'єднання
- •Формат даних
- •Управління виключеннями
- •Реляційне відображення об'єктів(Object Relational Mapping)
- •Процедури, що зберігаються
- •Транзакції
- •Перевірка вводу
- •Типи бізнес-процесів
- •Загальні правила складання сміття:
- •Вибір стратегії визначення виключень
- •Стратегія протоколювання виключень
- •Стратегія повідомлення про виключення
- •Ухвалення рішення про необхідність обробки необроблених виключень
- •Спеціальні питання проектування
- •Аутентифікація
- •Авторизація
- •Кешування
- •Мережева взаємодія
- •Управління конфігурацією
- •Управління виключеннями
- •Протоколювання
- •Управління станом
- •Проблеми, які виникають при проектуванні взаємодії
- •Загальні завдання проектування стратегії зв'язку
- •Обмін файлами
- •Розподілена база даних
- •Виклик видалених процедур
- •Обмін повідомленнями
- •Процедура передачі повідомлення включає 5 основних етапів:
- •Комерційні системи обміну повідомленнями
-
Сервери об’єктів
Сервер об’єктів (object server) – це сервер, орієнтований на підтримку розподілених об’єктів.
Важлива відмінність між стандартним сервером об’єктів та іншими серверами полягає в тому, що сам сервер об’єктів не надає конкретної служби, а лише засоби звертання до локальних об’єктів на основі запитів від відда- лених клієнтів. Конкретні служби реалізують об’єкти, розміщені на сервері, що дозволяє порівняно легко змінити набір служб, додаючи або видаляючи об’єкти. Сервер об’єктів, відповідно, відіграє роль місця для зберігання об’єктів.
Об’єкт складається з двох частин: даних, які відображають його стан, і коду, що створює реалізацію його методів (рис. 4.12). Чи будуть ці частини зберігатися окремо, а також чи зможуть методи спільно використовуватися декількома об’єктами, залежить від сервера об’єктів. Спосіб звертання сервера об’єктів до тих об’єктів, які на ньому зберігаються, має певні особливості.
Приклад. У багатопотоковому сервері об’єктів окремий потік виконан-
ня
може бути призначений окремому об’єкту або запиту на звертання до об’єкта.
Для будь-якого об’єкта, до якого виконується звертання, сервер об’єктів має знати, який код виконувати, з якими даними працювати, чи запускати окремий потік виконання для підтримки звертання тощо. Якщо вважати, що всі об’єкти виглядають однаково, то звертання до них можна утворювати однаково. Саме так працює середовище DCE. На жаль, такому підходу зазви- чай не вистачає гнучкості, через що він має певні обмеження у процесі ро- боти з розподіленими об’єктами.
Рис. 4.12. Структура сервера об’єктів
Найбільш логічний підхід з боку сервера – підтримувати різні правила обробки об’єктів. Розглянемо, як приклад, роботу з нерезидентними об’єктами. Нерезидентним називають об’єкт, який існує лише під час існування серве- ра, а можливо, і ще коротший термін. Типовою реалізацією нерезидентного об’єкта можна вважати копію файлу, яка зберігається в пам’яті, призначену лише для читання, наприклад калькулятор (який зазвичай запускається на високошвидкісному сервері). Доцільно створювати нерезидентний об’єкт під час першого запиту до нього, а знищувати після того, як не залишиться пов’язаних із цим об’єктом клієнтів.
Перевага такого підходу полягає в тому, що нерезидентні об’єкти викори- стовують ресурси сервера лише доти, доки в цих об’єктах є потреба; недолік –
у тому, що звертання потребує для виконання певний додатковий час на створення об’єкта. З огляду на це інколи застосовують інший підхід – всі нерезидентні об’єкти створюють у процесі ініціалізації сервера, виділяючи ресурси на об’єкти навіть у тому разі, якщо жоден клієнт не стане їх викори- стовувати.
Аналогічно сервер має можливість виділяти для кожного зі своїх об’єктів окремий сегмент пам’яті, тобто заборонити спільне використання об’єктами коду і даних. Такий підхід застосовують тоді, коли для реалізації кожного об’єкта не потрібно виокремлювати код від даних або коли об’єкти потрібно відокремити один від одного з міркувань безпеки, тобто сервер для гарантованого захисту меж сегментів має надати спеціальні засо- би вимірювання часу або вимагати підтримки від базової операційної сис- теми. У разі альтернативного підходу дозволяють об’єктам спільно вико- ристовувати код. База даних, що містить об’єкти, які належать до певного класу, може бути ефективно реалізована за рахунок однократного заванта- ження на сервер реалізації цього класу. В разі надходження запиту на звер- тання до об’єкта серверу достатньо отримати з бази даних стан об’єкта і виконати викликаний метод.
Аналогічно розрізняють інші підходи до роботи з потоками виконання. Найпростіший з них – реалізація сервера з єдиним керівним потоком вико- нання. Сервер може підтримувати і декілька потоків виконання – по одному на кожен об’єкт. У разі надходження запиту зі звертанням до об’єкта сервер передає запит потоку виконання, який відповідає за цей об’єкт. Якщо потік виконання у цей момент зайнятий, то запит стає в чергу. Перевага такого пі- дходу полягає в автоматичному захисті об’єктів від одночасного доступу. Для єдиного пов’язаного з об’єктом потоку виконання всі звертання вишико- вуються по черзі. Можна також виділяти окремий потік виконання кожному запиту, але необхідно заздалегідь запобігти одночасному доступу до об’єктів. Незалежно від того, чи призначається потік виконання кожному об’єкту або кожному методу, потрібно вирішити, чи створювати кожен потік за запитом, чи підтримувати на сервері пул потоків. Універсального оптимального рішення цієї проблеми бути не може.