- •Розподілені системи
- •Історична довідка
- •Базові терміни та визначення
- •Телекомунікаційні мережі як елемент розподілених систем
- •Модель клієнт–сервер
- •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 Relational Mapping)
-
При проектуванні об'єктно-орієнтованого застосування необхлдимо враховувати невідповідності між об'єктною моделлю застосування і ре- ляційною моделлю даних, а також чинники, які можуть утрудняти пере- творення між різними формами даних.
-
Необхідно розглянути можливість використання середовища( frame- work), яке підтримує об'єктне/реляційне відображення між сутностями сфери застосування і базою даних.
-
При роботі з невеликими застосуваннями може використовуватися ша- блон доступу до даних Сховище(Repository).
-
При роботі з Web - застосуваннями або службами необхідно підтриму- вати можливість завантаження тільки необхідних даних - ледаче заван- таження(lazy loading).
Запити
Запити є основним механізмом оперування даними на рівні даних. Запити є механізмом перетворення команд застосування в дії з виконання CRUD опе- рацій у базі даних.
-
Переважне використання що параметризуються запросоы SQL і пара- метрів, що типізуються, щоб уникнути атак SQL injection. Слід уникати злиття рядків при побудові динамічних запитів з призначених для кори- стувача вхідних даних.
-
Бажане застосування об'єктів для побудови запитів.
-
При побудові динамічних SQL запитів необхідно уникати змішення бі- знес-логіки і логіки, використовуваною для побудови запиту.
Процедури, що зберігаються
-
Необхідно враховувати, що використання динамічного SQL в проце- дурі, що зберігається, погано впливає на продуктивність, безпеку і прос- тоту підтримки застосування.
-
Необхідно уникати створення тимчасових таблиць при обробці даних. Якщо це необхідно переважно створення тимчасової таблиці в пам'яті а не на диску.
-
Слід проектувати обробку помилок і повертати значення, які можуть бути оброблені кодом застосування.
Транзакції
Транзакція - це обмін послідовними даними і пов'язаними з ними діями, які розглядаються як єдине ціле, з метою виконати запит і гарантувати цілісність бази даних.
Транзакція вважається завершеною, тільки якщо обробка усіх даних і усі дії завершені, тоді зміни відповідної бази даних стають постійними. Транзакції підтримують відміну(відкат) дій у разі виникнення помилки, що допомагає зберегти цілісність даних бази даних.
Важливо правильно вибрати модель паралельної обробки запитів і визначи- ти, як здійснюватиметься управління транзакціями. Існують моделі пара- лельної обробки запитів з песимістичним і оптимістичним блокуванням. При оптимістичному блокуванні дані не блокуються, і оновлення вимагають коду для перевірки. Зазвичай перевіряється, чи не змінилися дані з моменту останнього витягання, для цього використовуються тимчасові мітки. При пе- симістичному блокуванні дані блокуються і не можуть оновлюватися іншими операціями до зняття блокування.
При проектуванні транзакцій треба керуватися наступними рекомендаціями:
-
Використайте транзакції тільки у разі потреби. Ретельно продумайте межі транзакції, щоб забезпечити можливість повторних спроб і компози- ції. Можливо, для простих запитів явна транзакція не потрібна, але ви по- винні переконатися, що не порушуєте стандартної поведінки завершення і ізоляції транзакції для бази даних. За умовчанням база даних Microsoft SQL Server® виконує кожне SQL- вираження як окрему транзак- цію(режим автоматичного завершення транзакції).
-
Транзакції мають бути гранично короткими, щоб максимально скоро- тити час блокування. Намагайтеся уникати використання блокування для тривалих транзакцій або при доступі до спільно використовуваних даних, що може блокувати доступ до цих даних іншого коду. Не використайте блокування взаємовиключного доступу, що може призводити до конфлік- тів і взаємних блокувань.
-
Використайте відповідний рівень ізоляції, який визначає, як і коли змі- ни стають доступними іншим операціям. Необхідно знайти компроміс між забезпеченням несуперечності даних і частотою конфліктів. Високий рі- вень ізоляції забезпечить велику несуперечність даних, але негативно по- значиться на паралельній обробці в цілому. Нижчий рівень ізоляції забез- печить кращу продуктивність, понизивши кількість конфліктів, але і нижчу узгодженість даних.
-
При використанні класів простору імен System.Transactions рекоменду- ється застосовувати модель неявних транзакцій, що забезпечується об'єк- том TransactionScope(Зона дії транзакції) простору імен System.Transactions. Неявні транзакції виконуються не так швидко, як транзакції, створені вручну, або явні, але їх простіше реалізовувати, і вони забезпечують гнучкі і прості в обслуговуванні рішення проміжного шару. Створювані вручну транзакції краще реалізовувати в процедурі, що збері- гається.
-
Якщо немає можливості завершити або відкотити транзакцію або при використанні тривалих транзакцій, реалізуйте компенсаційні методи для повернення сховища даних в попередній стан у разі збою операції у рам- ках транзакції.
-
Якщо вимагається виконувати безліч запитів до бази даних, розглянете можливість застосування безлічі активних результуючих наборів(multiple active result sets, MARS), що забезпечить підтримку безлічі результуючих наборів тільки для пересилки і тільки для читання і дозволить виконувати безліч запитів з використанням одного підключення. MARS можуть бути корисні в застосуваннях з паралельною обробкою безлічі транзакцій.