Щойно кілька комп’ютерів різних моделей під управлінням різних операційних систем з’єднуються в мережу, одразу постає проблема: яким чином організувати узгоджену роботу їх у мережі. Передусім виникає питання про узгодження форматів представлення даних, оскільки в мережі можуть бути комп’ютери, що відрізняються розрядністю (16-, 32- і 64-розрядні процесори), порядком проходження байт у слові, представлення чисел із крапкою, із плаваючою комою тощо. Завдання комунікаційного сервера в клієнт-серверних технологіях полягає в тому, щоб на рівні обміну даними забезпечити узгодження їхніх форматів між віддаленими й локальними вузлами для того, щоб дані, зчитані з бази даних на віддаленому вузлі та передані мережею, були розпізнані прикладною програмою на локальному вузлі.
У неоднорідному комп’ютерному середовищі під час взаємодії клієнта і сервера виникає також завдання трансляції кодів. Сервер може працювати з однією кодовою таблицею, наприклад EBCDIC (Extended Binary-Coded Decimal Inter-
change Code) — розширений двійково-кодований десятковий код для обміну інформацією, а клієнт — з іншою, наприклад ASCII (American Standard Code Information Interchange). При цьому відбувається неузгодженість трактування кодів символів. Тому якщо на локальному вузлі використовується одна кодова таблиця, а на віддаленому — інша, то під час передавання мережею запитів і одержання на них відповідей необхідно забезпечити трансляцію кодів. Реалізація цього завдання лягає на комунікаційний сервер.
Якщо розглядати деталі взаємодії однієї пари «клієнт-сервер», то це не є надто складним завданням. Але за реальних умов сервер бази даних має обслуговувати одночасно безліч запитів від клієнтів. Отже, в будь-який момент таких пар може бути кілька. І всі проблеми взаємодії, про які йшлося вище, мають розв’язуватися комунікаційним сервером для всіх цих пар взаємодії.
Системи з архітектурою «один до одного» для обслуговування сервером БД одночасно безлічі клієнтів змушені завантажувати окремий комунікаційний сервер для кожної пари «клієнт-сервер». Унаслідок цього навантаження на операційну систему збільшується, різко зростає загальна кількість її процесів, що веде до збільшення витрат обчислювальних ресурсів. Це одна з вад архітектури «один до одного».
Саме тому в сучасних розподілених СУБД для усунення цієї вади передбачено багатопроцесорні або багатопотокові комунікаційні сервери. Наприклад, багатопотоковий комунікаційний сервер на кожному вузлі мережі підтримує безліч пар з’єднань «клієнт-сервер» і дає змогу існувати безлічі незалежних сеансів роботи з базами даних (MS SQL Server, Sybase SQL Server і т. ін.).
Вирішення завдань мережевої взаємодії клієнта і сервера за допомогою комунікаційного сервера є необхідною, але недостатньою умовою підтримки розподілених баз даних. Невирішеними залишаються такі завдання:
— управління іменами в розподіленому середовищі;
— оптимізація розподілених запитів;
— управління розподіленими транзакціями.
Перше завдання вирішується використанням глобального словника даних. Він зберігає інформацію про розподілену базу даних: розташування даних, можливості інших СУБД (якщо використовується шлюз), відомості про швидкість передавання даних мережею з різною топологією тощо.
Глобальний словник даних — це механізм відстеження розташування об’єктів у розподіленій БД. Дані можуть зберігатися на локальному вузлі чи на обох вузлах, але розташування їх має залишатися прозорим як для кінцевого користувача, так і для програми. У програмі не потрібно явно вказувати місце розташування даних. Вона має бути цілковито незалежною від того, на яких вузлах розміщеною дані, з якими вона оперує.
Друге завдання потребує інтелектуальних засобів розв’язання. Розподілений запит стосується багатьох баз даних на різних вузлах, причому обсяги вибірки можуть бути дуже різними. Передусім він заторкує таблиці, що належать різним локальним БД. Для нормального виконання запиту необхідно мати обидві вихідні таблиці на одному вузлі. Отже, одну з таблиць треба передати мережею. Звітно, це має бути таблиця меншого розміру. Тому оптимізатор розподілених запитів обов’язково має враховувати розмір таблиць, інакше запит буде виконуватися непередбачено довго.
Крім розміру таблиць оптимізатор розподілених запитів повинен ураховувати безліч додаткових параметрів, таких як статистика розподілу даних за вузлами, обсяг даних, переданих між вузлами, швидкість комунікаційних ліній, структура збереження даних, співвідношення продуктивності процесорів на різних вузлах тощо. Уся ця інформація саме й міститься в глобальному словнику даних.
Третє завдання — управління розподіленими транзакціями — виконується за допомогою спеціального механізму — двофазової фіксації транзакції, спеціального протоколу двофазової фіксації транзакції — 2РС (див. п. 4.1).
Виконання всіх трьох завдань, про які йшлося вище, покладено на спеціальний компонент СУБД — сервер розподілених баз даних (DDS — Distributed Database Server).
У разі, коли локальна база даних розташована на одному вузлі, сервер БД і прикладна програма виконуються там же, тож непотрібні ані комунікаційний сервер, ані сервер розподіленої БД.
Коли ж прикладна програма виконується на локальному вузлі, БД перебуває на віддаленому вузлі і там же виконується сервер БД, то на віддаленому вузлі необхідний комунікаційний сервер, а на локальному — сервісна комунікаційна програма.
Якщо розподілена БД складається з таблиць локальних БД, що перебувають на одному вузлі, і там само функціонує сервер розподіленої БД і виконується прикладна програма, то комунікаційний сервер непотрібен, бо немає взаємодії з мережею. Якщо ж локальні бази даних розташовані на кількох вузлах, то для доступу до розподіленої БД необхідні і сервер розподіленої БД, і комунікаційний сервер.
Однією з найважливіших вимог до сучасних клієнт-серверних технологій, а точніше до СУБД, на основі яких вони функціонують, є міжоперабельність (або інтероперабельність). Цю якість можна трактувати як відкритість системи, що дозволяє вбудовувати її як компонент у складне різнорідне розподілене на значній відстані середовище. Вона досягається як використанням інтерфейсів, що відповідають міжнародним, національним і промисловим стандартам, так і за рахунок спеціальних рішень.
Для промислових СУБД ця якість означає таке:
— можливість прикладних програм (додатків), створених засобами розроблення даної СУБД, оперувати над базами даних іншої СУБД (у «чужому» форматі) так, начебто маємо справу із власними базами даних;
— СУБД повинна мати властивість, яка дає їй змогу бути постачальником даних для будь-яких додатків, створених засобами розроблення третіх фірм, що підтримують деякий стандарт звернення до баз даних.
Перше завдання виконується використанням шлюзів, які дозволяють здійснювати доступ до БД в іншому форматі.
Наприклад, шлюз Informix-Enterprise Gateway (EG) забезпечує для інструментальних засобів і додатків баз даних, виконуваних під управлінням операційних систем UNIX або MS Windows, доступ до інформації, що зберігається в базах даних понад 60-ти типів, серед яких Oracle, Sybase, Ingres, Adabas, IMS і т. ін. Доступ реалізується за допомогою програмних продуктів Enterprise Data Access
SQL (EDA/SQL) компанії Information Builders. Шлюз дає змогу виконувати розподілені з’єднання таблиць із різнорідних баз даних та імпортувати дані інших форматів («чужі») в бази даних Informix. Enterprise Gateway виконується як процес сервера баз даних Informix, який конвертує запити клієнтів Informix у запити EDA/SQL. Коли від клієнтського додатка надходить інструкція SQL або віддалений виклик процедури, призначеної для Enterprise Gateway, то вони адресуються на EDA/SQL Ser-ver, який звертається до відповідних реляційних або нереляційних джерел даних.
Дані, отримані від EDA/SQL Server, Enterprise Gateway повертає клієнту.
Кінцеві користувачі звертаються до Enterprise Gateway так само, як до сервера баз даних Informix. Доступ на читання і запис здійснюється за допомогою інструкцій SQL, що відповідають стандарту синтаксису ANS1-92, або віддалених викликів процедур (RPC — Remote Procedure Call).
Доступ за допомогою RPC забезпечується для інструментів розроблення і додатків Informix, а також третіх фірм. Віддалені виклики процедур EDA/SQL виглядають як звернення до процедур, що зберігаються, тому для їх використання в додатки слід внести мінімальні зміни.
Для оброблення багаторядкових наборів даних, отриманих унаслідок виконання RPC або інструкції SQL, в Enterprise Gateway підтримується механізм прокручуваних курсорів (Scroll Cursors), який уможливлює здійснювати прямий і зворотний перегляд наборів даних.
Друге завдання вирішується використанням відкритого інтерфейса ODBS (Open Data Base Connectivity).
Сучасні корпоративні інформаційні системи потребують доступу до різнорідних баз даних. Це означає, що в прикладній програмі для реалізації запитів до баз даних мають бути використані такі засоби, щоб запити були зрозумілі різним СУБД, як реляційним, так і тим, що спираються на інші моделі даних. Одним із можливих способів розв’язання цієї проблеми є узагальнений набір різних діалектів мови SQL, як це зроблено, наприклад, у СУБД Open Ingres. Інформаційна система, в якій кілька комп’ютерів різних моделей і виробників об’єднані в мережу і на кожному з них функціонує власна СУБД, називається гетерогенною.
Проблеми сполучення неоднорідних комп’ютерних систем з відкритим розподіленим середовищем розглянемо на прикладі стандарту DСE.
Стандарт Distributed Computing Environment (DCE), запропонований 1990 року фондом відкритого програмного забезпечення (Open Software Foundation — OSF), являє собою набір специфікацій програмних сервісів, які дають змогу об’єднувати апаратно-програмні платформи різних постачальників в інтегроване розподілене обчислювальне середовище [24]. Цей стандарт підтримується такими виробниками, як Hewlett Packard, Digital Equipment, IBM, Sun, які запровадили відповідні сервіси у свої операційні системи.
Стандарт DCE привертає дедалі більшу увагу як системних аналітиків, так і потенційних користувачів. Але щоб підприємства могли реально скористатися перевагами інтеграції, тобто створювати програмні додатки для DCE і перено-
сити в це середовище наявні прикладні програми, потрібні засоби. Прикладом такого інструментального засобу може слугувати програмний продукт компанії Informix — DCE/Net [26]. Informix — DCE/Net відкриває доступ до сервісів DCE для всіх інструментальних засобів Informix, а також будь-яких додатків чи інструментальних комплексів від незалежних постачальників, які використовують стандартний доступ до даних ОDВС. Ідея DCE полягає в тому, щоб примусити неоднорідну децентралізовану розподілену обчислювальну систему функціонувати як єдиний логічно поєднаний обчислювальний ресурс. Сервіси DCE покликані ізолювати від розподіленого додатку, що виконується в такому середовищі, внутрішню складність мережевого обчислювального комплексу. DCE містить:
— сервіс безпеки;
— сервіс імен (директорій);
— віддалені виклики процедур;
— бібліотеку потоків;
— розподілений файловий сервіс;
— розподілений сервіс часу.
Розглянемо перелічені компоненти і практичні аспекти їх використання в Informix — DCE/Net.
Сервіс безпеки. Він є головним компонентом у реалізації взаємодії «клієнтсервер» у середовищі DCE. Основні функції, що їх реалізує сервіс безпеки, це автентифікація, перевірка повноважень і кодування. Віддалені виклики процедур DCE тісно інтегровані із сервісами безпеки; це дає змогу знаходити порушення цілісності повідомлень, що передаються, і забезпечувати їх конфіденційність. Informix — DCE/Net використовує всі засоби забезпечення безпеки, що надаються DCE. Наприклад, для кожного додатка клієнт-сервер адміністратор може задавати один із п’яти рівнів захисту:
— захист даних, що пересилаються, лише під час встановлення з’єднання клієнта із сервером;
— захист даних лише на початковому етапі виконання віддаленого виклику процедури, коли сервер уперше отримує запит;
— гарантію істинності джерела даних. Перевіряється, що всі дані, які надходять на сервер, отримано від відповідного клієнта;
— гарантію істинності джерела і цілісності даних. Перевіряється, що відправлені дані не були змінені;
— гарантію істинності джерела, цілісності та конфіденційності даних.
Виконуються перевірки, передбачені на попередньому рівні, здійснюється кодування всіх даних, що пересилаються.
Сервіс автотентифікації DCE, підтримуваний Informix — DCE/Net, істотно поліпшує характеристики безпеки розподіленого середовища. Достатньо мати єдине вхідне ім’я і пароль для DCE, щоб мати доступ до будь-якої бази даних в цьому середовищі. Під час запуску додатка Informix — DCE/Net запитує автотентифікаційну інформацію користувача в DCE і підключає його до необхідної бази даних.
Наявність єдиної точки адміністрування вхідних імен і прав доступу до баз даних і додатків сприяє впорядкуванню загальної ситуації безпеки. Наприклад,
якщо знищити вхідне ім’я користувача в DCE, то адміністратор може бути впевнений, що цей користувач уже не зможе отримати доступу до жодного із системних ресурсів.
Сервіс імен. Цей сервіс забезпечує найменування ресурсів і надає користувачам і прикладним програмам прозорий доступ до ресурсів за іменами.
Виокремлюють два рівня сервісу імен — локальний і глобальний. Локальний сервіс забезпечує присвоєння імен у межах так званих комірок DCE, де під коміркою розуміють групу користувачів, систем і ресурсів, об’єднаних виробничою чи територіальною єдністю.
Глобальний сервіс імен об’єднує комірки DCE в єдине середовище найменування на основі промислового стандарту директорій (стандарт Х.500). Informix — DCE/Net використовує локальний сервіс директорій для зберігання імен і місцезнаходження баз даних. Отже, у прикладній програмі достатньо вказати фіксоване DCE
— ім’я бази даних (наприклад KADR), яке не доведеться змінювати під час переміщення бази даних на інший сервер.
Віддалені виклики процедур (RPC — Remote Procedure Call). Модель віддалених викликів процедур у DCE розширює модель традиційного процедурного програмування, вможливлює здійснення викликів процедур на віддалених серверах так само просто, як і виклики локальних процедур. Informix — DCE/Net реалізує всі мережеві комунікації засобами DCE RPC, які сумісні з великою кількістю операційних систем, а тому доступ до баз даних не залежить від використовуваних апаратно-програмних платформ. Незалежність DCE RPC від мережевих протоколів дає змогу розгортати додатки DCE в мережі будь-якого типу.
Бібліотека потоків. Бібліотека потоків — це спосіб реалізації паралельного виконання кількох дій у рамках одного додатка. Прикладний програмний інтерфейс (АРІ) потоків DCE, сумісний зі стандартом POSIX (Portable Operating System Interface), дозволяє створювати й контролювати в межах процесу виконання багатьох потоків, синхронізувати доступ їх до глобальних даних.
Клієнтська і серверна частини Informix — DCE/Net використовують засоби асинхронного оброблення, що їх надає механізм потоків. Додаток може виконувати одночасні підключення до кількох баз даних під управлінням СУБД різних типів завдяки універсальності інтерфейсу ОDВС. Розробнику додатків не потрібно для цього вникати в тонкощі багатопотокового програмування: управління потоками, що реалізують багатопрофільне підключення, виконує клієнт Infor-mix — DCE/Net.
Розподілений файловий сервіс (DFS — Distributed File Service). Сервіс DFS виокремлений як підсистема DСЕ, оскільки він складається з низки додатків і доменів, які в сукупності реалізують глобальну файлову систему, досяжну для всіх комірок DСЕ.
Розподілений сервіс часу. Сервіс часу забезпечує точну, стійку до відмови синхронізацію системного часу в межах як локальних, так і глобальних мереж. Він необхідний для роботи сервісів безпеки та імен.
На рис. 2.8 наведено архітектуру дворівневого прикладного середовища клієнт-сервер на основі Informix — DCE/Net.
Рис. 2.8. Архітектура клієнт-серверного середовища із використанням Informix — DCE/Net
Характерною рисою цієї архітектури є те, що менеджер процесу звертається не до драйвера (у традиційному варіанті виклики за допомогою ОDВС надсилаються менеджеру драйверів ОDВС, який передає їх для виконання одному із драйверів ОDВС для конкретної СУБД), а до клієнтського компонента Informix — DCE/Net. Клієнтський компонент Informix — DCE/Net — це невелика проміжна програма, яка сприймає виклики ОDВС, упаковує їх і передає мережею, використовуючи віддалений виклик процедур DСЕ. Informix — DCE/Net для Win-dows реалізований у вигляді бібліотек (DLL), що завантажуються динамічно, тому під час перенесення Windows-додатків у середовище DСЕ не потрібна перекомпіляції чи переробка їх.
