Розвиток клієнт-серверних систем. Стандарти архітектури клієнт - сервер в управлінні інформації

Типовий розподіл функцій між клієнтами і серверами.

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

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

З іншого боку, іноді хотілося б перенести більшу частину прикладної системи на сторону сервера, якщо різниця в потужності клієнтських робочих станцій і сервера надто велика. Взагалі ж при використанні RPC це зробити неважко. Але потрібно, щоб базове програмне забезпечення сервера дійсно дозволяло це. Зокрема, при використанні ОС UNIX проблеми практично не виникають.

Структура СБД з виділенням клієнтів і сервера

Сервер — це власне СКБД. Він підтримує всі основні функції СКБД і надає повну підтримку на зовнішньому, концептуальному і внутрішньому рівнях.

Клієнти — це різні додатки, які виконуються над СКБД.

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

Зазвичай в додатку виділяються наступні групи функцій:

функції введення і відображення даних;

• прикладні функції, що визначають основні алгоритми рішення задач додатку;

• функції обробки даних усередині додатку;

• функції управління інформаційними ресурсами;

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

Функції введення і відображення даних — презентаційна частина додатку — визначаються тим, що користувач бачить на своєму екрані, коли працює додаток. Тому основними завданнями цієї частини додатку є:

• формування екранних зображень;

• читання і запис в екранні форми інформації;

• управління екраном;

• обробка рухів миші і натиснень клавіш клавіатури.

Прикладні функції визначають основні алгоритми рішення конкретних задач додатку. Зазвичай код додатку пишеться з використанням різних мов програмування, таких як С++, Visual C++,Cobol, SmallTalk, Pascal, Delphi.

Функції обробки даних пов'язані з обробкою даних усередині додатку.

Даними управляє власне СКБД. Для забезпечення доступу до даних використовуються мова запитів і засобу маніпулювання даними — стандартної мови Structured Query Language (SQL). Зазвичай оператори мови SQL вбудовуються в мови, які використовуються для написання коду додатку.

Функції управління інформаційними ресурсами (процесор управління даними) — це власне СКБД, яка забезпечує зберігання і управління базами даних.

Службові функції виконують роль зв'язок між функціями інших груп.

У локальних СКБД всі перераховані компоненти додатку розташовуються в єдиному середовищі і комбінуються усередині однієї виконуваної програми.

У мережевих СКБД ці частини додатку розподіляються по мережі.

Якщо всі п'ять компонентів додатку розподіляються тільки між двома процесами, які виконуються на двох платформах: на клієнті і на сервері, то така архітектура СКБД називається дворівневою. Вона має декілька основних різновидів - файл-серверні і клієнт-серверні архітектури.

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

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

SQL Access Group і стандарт DRDA

Процес стандартизації доступу до баз даних клієнт-сервер придбав найбільшу активність у кінці 80-х - початку 90-х рр. У 1989 р. утворилася група SQL Access Group (SAG). Вона є консорціумом з 42 компаній, до числа яких входять видатні постачальники СУБД і різних інструментальних засобів систем баз даних.

Одним із завдань SAG було визначення специфікацій форматів і протоколів (Formats And Protocols, FAP) для комунікацій в системах баз даних клієнт-сервер на основі специфікацій Видаленого доступу до баз даних (Remote Database Access, RDA), розроблених Міжнародною організацією по стандартизації (International Standards Organization, ISO). Стандарт RDA описаний в документі ISO/IEC 9579, Інформаційні технології - Мови баз даних - Видалений доступ до баз даних (ISO/IEC 9579, Information Technology Database Languages - Remote Database Access), який складається з двох частин: Загальна модель, сервіс і протокол (Generic Model, Service and Protocol) і Спеціалізація SQL (SQL Specialization). Друга частина цього документу і стала основою специфікацій FAP, запропонованих групою SAG.

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

Приблизно в той же час компанія IBM, єдиний великий постачальник засобів для баз даних, що не увійшов до групи SAG, ввела стандарт "Архітектура розподілених реляційних баз даних" (Distributed Relational Database Architecture, DRDA), що ніяк не узгоджується з ISO RDA (хоча обоє ці абревіатури містять три загальні букви, проте букви "R" і "А" в назвах цих стандартів означають різні слова).

SQL Access Group (SAG)

- Специфікації на основі стандарту ISO RDA

- Мета: стандарт де-юре

- "Відкриті" компоненти

DRDA

- Початкова мета: доступ до баз даних IBM у рамках SAA

- Може стати стандартом де-факто

- Використовує компоненти IBM

Початковою метою DRDA була інтеграція баз даних у рамках системної архітектури застосувань (System Application Architecture, SAA), запропонованою IBM. Спочатку SAA розглядалася як головний засіб інтеграції для чотирьох платформ IBM (MVS, VM, OS/400 і OS/2). Використовуючи DRDA і SAA, можна об'єднати менеджери баз даних для цих платформ (DB2, SQL/DS, OS/400 Data Manager і OS/2 Extended Edition Database Manager відповідно) в єдину модель клієнт-сервер.

У 1991 р. IBM запропонувала архітектуру сховища інформації (Information Warehouse), в якій DRDA була відведена ключова роль в інтеграції баз Даних клієнт-сервер, керованих різними програмними продуктами, і ряд постачальників засобів баз даних оголосили про свою підтримку DRDA. Таким чином, на початку 1992 р. в області стандартизації доступу до баз даних клієнт-сервер утворилися два "табори" - SAG, що спирається на стандарт RDA, і прибічники DRDA, орієнтованого на платформи IBM.

Оскільки SAG представляла і представляє ініціативу безлічі постачальників, спрямовану на процес формальної стандартизації, то результат її зусиль стане стандартом де-юре, заснованим організаціями по стандартизації за допомогою формальних процедур. Навпаки, DRDA, незважаючи на підтримку ряду постачальників, може мати лише статус корпоративного стандарту компанії IBM подібно до інших специфікацій, запропонованим IBM, таким, як SNA або комунікації за допомогою терміналу 3270.

Між специфікаціями SAG і DRDA існує ряд технічних відмінностей. Оскільки специфікації FAP, запропоновані SAG, засновані на ISO RDA, то компоненти ISO, у тому числі абстрактний синтаксис ASN.l (Abstract Syntax Notation, ASN) і базові правила кодування (Basic Encoding Rules, BER) для ASN.l, використовуються як синтаксис передачі повідомлень (Transfer Syntax), хоча синтаксис фактичних повідомлень встановлюється індивідуально для кожного з'єднання шляхом узгодження. На відміну від цього DRDA спирається на архітектуру управління розподіленими даними IBM (Distributed Data Management, DDM), а саме на її третій рівень, який визначає абстрактний синтаксис і правила кодування команд і повідомлень у відповідь. Для представлення даних і метаданих в DRDA використовується архітектура IBM FD: OCA, вживана також для представлення складних документів.

Стандарти, засновані на інтерфейсі рівня викликів SAG

У 1992 р. виникли відразу два конкуруючі стандарти - ODBC і IDAPI, і обоє вони засновані на інтерфейсі рівня викликів (Call - Level Interface, CLI), запропонованому SAG. Перший з них - Відкритий інтерфейс доступу до баз даних (Open DataBase Connectivity, ODBC) був введений і активно просувався компанією Microsoft. Метою Microsoft було надання додаткам Microsoft Windows доступу до баз даних, заснованих на SQL, за допомогою стандартизованного інтерфейсу клієнт-сервер (малюнок 3.1.). Головне призначення ODBC - перетворити SAG CLI з абстрактного узагальненого стандарту в живе середовище, в якому він може безпосередньо використовуватися в додатках для ПК.

Приложение Microsoft Widows

ODBC

ODBC

Сервер

Малюнок 3.1. - Архітектура ODBC

Декількома місяцями пізніше, в листопаді 1992 р., група компаній під керівництвом Borland (що включає також IBM, Novell і WordPerfect) оголосила аналогічний стандарт інтерфейсу для систем баз даних клієнт-сервер, що також заснований на SAG CLI і дістав назву Інтерфейсу прикладного програмування для інтегрованих систем баз даних (Integrated Database Application Programming Interface, IDAPI). Архітектура IDAPI показана на малюнку 3.2. Стандарт IDAPI концептуально аналогічний ODBC. Обидва стандарти специфікують інтерфейси клієнт-сервер, засновані на SAG CLI, але IDAPI спочатку був орієнтований, окрім Microsoft Windows, також і на інші платформи і надавав на додаток до SQL -доступу також і навігаційний доступ до серверів баз даних.

Стандарт IDAPI прийшов на зміну іншому корпоративному стандарту компанії Borland - Інтерфейсу прикладного програмування об'єктних баз даних (Object Database API, ODAPI), який був частиною Компонентної об'єктної архітектури Borland (Borland Object Component Architecture, BOCA).

Стандарт IDAPI забезпечує підтримку серверів dBase (див. малюнок 3.2.). Більшість програм dBase використовують навігаційний доступ до баз даних (наприклад, модель оновлення мастер-таблицы із застосуванням транзакційної таблиці, двонаправлений перегляд інформації в таблицях і тому подібне), а не SQL -подобные операції рівня великих кількостей. Тому IDAPI у своєму інтерфейсі містить навігаційний компонент NAV/CLI, який дозволяє мати на серверній стороні новостворюваних середовищ додатків існуючі бази даних dBase (системи баз даних, успадковані зі світу ПК). Те ж можна сказати і про інші драйвери серверної частини IDAPI, наприклад про СУБД Paradox компанії Borland.

Пользовательское приложение

Пользовательское приложение

IDAPI API (SQL\CLI и NAV\CLI)

Технология IDAPI

Драйвер dBase

Драйвер Oracle

Драйвер DB2

Драйвер Sybase

Малюнок 3.2. - Технічна архітектура IDAPI

На малюнку 3.3. показано співвідношення між стандартами ODBC і IDAPI сьогодні і, можливо, в майбутньому. Коли був оголошений стандарт IDAPI, голова трупи SAG заявив, що SAG вивчить ті, що містяться в IDAPI розширення базового стандарту SAG CLI, і це означає, що навігаційні засоби, можливо, будуть введені також і в SAG CLI.

Матеріали проекту специфікацій IDAPI містили 149 сторінок описів операторів рівня викликів як частини інтерфейсу прикладного програмування (Application Programming Interface, API). Ці оператори були розділені на наступні категорії:

- Середовище і з'єднання Відкриття і закриття з'єднань з серверами, управління дескрипторами (handles), управління курсорами.

- Ресурси і можливості. Управління конфігураційними файлами.

- Каталоги і схеми Управління шляхами доступу до схемної інформації.

- Підготовка і виконання операторів. Функції для прямого виконання SQL -операторов, підготовки і наступного виконання операторів, отримання кількості рядків, що зачіпають тим або іншим оператором SQL, і тому подібне

- Визначення даних. Створення і модифікація таблиць, створення індексів, знищення таблиць і індексів.

- Маніпулювання даними. Оновлення і видалення рядків, управління блокуваннями рядків і таблиць, управління великими бінарними об'єктами (Binary Large OBject, BLOB), відкриття курсорів.

- Управління транзакціями. Фіксація і відкат транзакцій, а також функції відміни виконання окремих SQL -операторов

- Діагностика Повернення інформації про помилки

- Розширення, специфічні для конкретних СУБД/операційних систем. Управління паролями, управління файлами, інші системозависимые функції.

- Різне. Нині ця категорія містить одного оператора, що знаходить перший рядок, ключ якого зіставляється з деяким заданим значенням (аналог операторів FIND або SEEK в мові Хbаsе).

Читачі, яким цікаво ознайомитися з типами операторів, включеними в специфікації даних стандартів, можуть звернутися безпосередньо до Проекту IDAPI (Working Draft IDAPI), доступного від Borland, або до аналогічних документів ODBC, доступних від Microsoft.

Малюнок 3.3. - Стандарти ODBC і IDAPI сьогодні і завтра

Дата добавления: 2014-01-04