Наше століття називають інформаційним, і в останні роки маса людей вже відчула це, завдяки сформувалася комунікаційної інфраструктури і, в чималому ступені, технології WWW. Для всіх великих організацій і величезної кількості дрібніших питання забезпечення зручного і вільного доступу до своєї інформації стає в ряд найбільш важливих.
Великі надії на підвищення якості і продуктивності праці покладаються на розвиток інформаційних технологій всередині самих компаній (intranet). Інформація, що раніше існувала лише на папері, і хоча б тому, доступна не всім, кому вона могла б бути корисна, архіви, на пошук необхідної інформації в яких йшли людино-роки, трудомістке складання анотацій на наукові і технічні статті (фахівець не може сам стільки прочитати!) - все це поступово відходить у минуле, поступаючись своїм місцем серверів WWW, повнотекстових пошукових систем і реляційних (і в дещо меншій мірі об'єктним) СУБД.
Глобальна мережа (Internet) в своєму чистому вигляді - як повністю відкрите середовище - все ширше застосовується для маркетингу і торгівлі. Цікава тенденція: "звичайні" способи реклами - телебачення, періодика - все частіше використовуються для реклами серверів WWW, на яких, власне, і розміщується розгорнута реклама продуктів і послуг. Не кажучи вже про торгівлю через Internet, яка поки ще перебуває в початковій стадії свого розвитку.
Парадокс ситуації полягає в тому, що важливість розвитку Internet / intranet розуміють всі, проте безпосередня віддача від вкладень відчувається далеко не всіма. Парадокс, однак, здається. Якщо та чи інша компанія проігнорує Internet або intranet, її конкуренти отримають значні переваги, і мова піде про збитки, втрати ринку і таке інше. Це майже 100% вірно для комп'ютерних компаній, судячи з активності інформаційних агентств і виробників автомобілів, для них Internet так само важливий. А решта ... Ну скажіть, хіба не приємно і корисно, перш ніж вирушати в магазин, відвідати www.whirpool.com, www.philips.com, www.panasonic.com або www.aiwa.com? А в тому, що у заводу "Рубін" свого сервера WWW немає, покупець не винен.
Інформацію, що поміщається на WWW, ми можемо умовно розділити на представлену у вигляді гіпертекстів (звичайні файли в форматі HTML) і розміщену в різних базах даних.
У першому випадку мова йде про цілий програмному конвеєрі, що дозволяє більш ніж на 90% зменшити витрати ручної праці при зміні та поповненні матеріалу. При цьому автоматично дотримується загальний художній стиль і т.д.
У випадку з базами даних інформація вже організована, накопичена і оновлюється за допомогою традиційних додатків. Тут мова йде про додаткову можливість звертатися до даних з Internet / intranet, а саме за допомогою універсального клієнтського додатка перегляду - браузера - Netscape Navigator або Microsoft Explorer, наприклад.
Нове покоління всіх систем управління базами даних має відповідні інтерфейси, однак вони ще далекі від повсюдного поширення. Найбільшою комерційної "масою" сьогодні мають реляційні СУБД, і про доступ до них піде мова в цій статті. Так уже склалося, що автори цієї статті зв'язали свою долю з СУБД Informix, тому ми спробуємо розповісти про те, як винести для загального користування бази даних, керовані Informix-ONLINE. Ці ж методи годяться і для роботи з практично будь-який інший сучасної СУБД.
Отже, уявімо собі одну із завдань інтеграції реляційної СУБД в середу Internet. Це може бути, наприклад, простенька програма реєстрації відвідувачів сервера WWW або повноцінний інтерфейс до серйозної інформаційної системі. І в тому і в іншому випадку треба зробити дві речі: запрограмувати алгоритми і інтерфейс користувача і забезпечити формування запитів до бази даних, з подальшою передачею таких на сервер СУБД і обробкою результатів.
Інтерфейсна частина Internet-додатки найчастіше реалізується за допомогою мови HTML. Коли потрібен більш потужний і інтерактивний інтерфейс, наприклад електронна таблиця, в поєднанні з HTML застосовується Java. Про те, як звертатися до СУБД з цих мов, і піде наша подальша розмова.
інтерфейс CGI
Найбільш простим і зручним способом побудови інтерактивних додатків на WWW є використання Common Gateway Interface (CGI). Схема взаємодії клієнта і сервера будується в даному випадку наступним чином:
- Універсальний Internet-клієнт (броузер) завантажує форму запиту (у вигляді HTML-документа), заповнює її і повертає заповнену форму на HTTP-сервер.
- Сервер викликає програму обробки, відповідну формі, яка називається CGI-скриптом.
- Скрипт отримує вміст полів запиту, виконує запит і генерує результат у відповідному вигляді. Це може бути новий HMTL-документ, файл з графічною інформацією або звуковий образ.
- Результат інтерпретується універсальним клієнтським додатком також, як і будь-який інший вихідний документ.
Отже, для забезпечення доступу до сервера баз даних INFORMIX-ONLINE треба написати програму (CGI-скрипт), яка буде шлюзом між браузером і сервером баз даних. Програма повинна аналізувати переданий від користувача запит, виконувати перевірку прав доступу цього користувача, ім'я та пароль якого передаються в запиті або по HTTP-протоколу і потім звертатися до сервера баз даних. Результат виконання запиту програма повинна приводити до виду, який може безпосередньо відобразити броузер (мова HTML).
Деякі переваги такого рішення полягають в тому, що сервер баз даних може знаходиться всередині захищеної мережі (віддалений користувач не звертається безпосередньо до СУБД, замість цього він викликає проміжну програму - CGI-скрипт, що виконується на загальнодоступною машині), а так само в тому, що розмежування прав доступу (передача на сервер імені користувача і пароля) може здійснюється стандартним для WWW способом.
CGI-скрипти можуть бути вкладеними. Наприклад, при необхідності виведення графічної інформації, скрипт, до якого йде звернення, вставляє в генерований їм HTML-файл посилання на зображення, проте при цьому в якості URL вказуються не файли, а знову ж таки CGI-скрипт. Як параметр йому передається інформація (в тому ж URL), по якій можна однозначно ідентифікувати і витягти з бази потрібне зображення (яке зберігається у вигляді BLOB). Точно також організовується і робота зі звуком.
Названі вище програми можуть бути написані з застосуванням будь-якої мови програмування, наприклад ESQL / C або 4GL. При цьому для реалізації функцій введення / виводу за стандартом CGI зручно використовувати бібліотеки, розроблені фірмою спеціально для цієї мети. Вони вільно поширюються, їх можна отримати на WWW-сервері фірми INFORMIX Software ( http://www.informix.com ). У цьому випадку відпадає необхідність у вивченні деталей реалізації CGI. Розробники прикладного програмного забезпечення можуть легко створювати WWW- версії своїх продуктів, не виходячи за рамки звичного середовища розробки.
Зручним спеціалізованим засобом для створення вищеописаних CGI- скриптів, що забезпечують доступ до серверів баз даних, виявився продукт під назвою Database Connector, що входить до складу пакету Esplanade (Web-сервер для Windows NT) фірми FTP Software. Він являє засоби генерації HTML-форм, а також CGI-програму, їх обробну. Для доступу до сервера баз даних використовується уніфікований інтерфейс "Open Database Connectivity" (ODBC). Немає необхідності вручну створювати HTML-файли, SQL-запити і CGI- скрипти, що істотно скорочує час розробки.
З'єднання по TCP / IP
Іноді технологія CGI-скриптів виявляється не дуже зручною. Конкретно, це трапляється, коли значна частина обробки інформації відбувається на клієнтській машині (клієнтську програму "розумне"). У цих випадках додаток, отримавши дані від віддаленого сервера, саме бажає їх обробити перед виведенням на екран. Крім того, програміст може побажати відкрити повноцінне постійне з'єднання з базою даних, як це робиться при традиційному програмуванні на ESQL / C, 4GL або NewEra.
У випадку з CGI це не завжди оптимально, так як CGI-скрипт буде працювати кожен раз, коли необхідно зробити запит, відпрацьовує і завершується, закриваючи всі з'єднання, і, "забуваючи" про який викликав її клієнта. При наступному запиті все починається з початку, включаючи передачу імені користувача та пароля, відкриття з'єднання з сервером баз даних, авторизації користувача і т.д. Крім того, що це накладно, при такому механізмі клієнтську програму не може зробити навіть таку дрібницю, як установка, що розділяється блокування на базу, з якої воно працює ...
Добре, запитаєте ви, яке відношення "розумні" додатка мають до Internet. Адже Internet - це Mosaic, Netscape та ін., Які вміють тільки відображати на екрані відформатовані тексти. Традиційні програми пишуться на 4GL, ESQL / C і легко з'єднуються з сервером через "рідні" засоби зв'язку Informix. Відповідь тут проста - Java. Програма-броузер з підтримкою Java може стати "розумним" додатком, якщо в неї завантажити програму на цій самій Java. А як з'єднувати Java-додаток з сервером БД? Через CGI?
На щастя програма на Java може відкрити звичайне з'єднання через TCP / IP з програмою на віддаленій машині. Однак підключитися безпосередньо до сервера БД не можна - для цього треба запрограмувати мережевий протокол (практично написати ESQL / Java, що ми зробити не можемо, тому що не знаємо протоколу).
Отже, ми бачили для себе єдиний спосіб вирішити проблему повноцінного з'єднання Java-додатка з сервером БД фірми Informix - написати свій власний проміжний (relay) модуль, який, будучи запущеним на віддаленому сервері, спілкувався б з сервером БД звичайним способом (бібліотеки ESQL / C , наприклад). Додаток ж при цьому з'єднується з проміжним модулем по нашому власному протоколу, що дозволяє розробникам легко адаптувати отриману систему клієнт-сервер до мінливих вимог. Скажімо, в дану схему легко вбудовується підтримка Kerberos.
Треба відзначити, що автори не концентрувалися саме на підтримку Java, хоча система розроблялася в рамках Java-проекту. Ми хотіли зробити рішення, придатне для підключення будь-якого клієнта, що вкрай важливо для платформ, які не підтримуються засобами розробки Informix, таких як DOS, OS / 2, Linux та ін. Це вплинуло і на засіб розробки - ми обмежилися стандартними C. Сам проміжний модуль в рамках нашого проекту отримав назву SQLD.
Програма SQLD є сполучною ланкою між додатками і віддаленим сервером баз даних. Зв'язок здійснюється за допомогою TCP / IP. SQLD отримує від програми оператор SQL, виконує його на сервері баз даних і видає, якщо необхідно, результат виконання оператора (наприклад, результат виконання оператора SELECT) назад клієнту.
Крім виконання функції посередника між додатком і сервером баз даних, SQLD дозволяє клієнтського додатку виконувати команди мови SHELL на віддаленій машині - тієї, на якій запущений SQLD. Як ви розумієте, це відкриває перед користувачем клієнтської програми технічно необмежений доступ до ресурсів віддаленого комп'ютера, а так само до інших комп'ютерів віддаленої локальної мережі (будь ласка не змішуйте технічні можливості зі вседозволеністю - будь-які звернення до сервера БД і до програм управляються засобами обмеження доступу UNIX, NT і Informix).
Останнє, що слід особливо відзначити - це підтримка російської мови. Як відомо, в нашій країні застосовується кілька різних уявлень російського алфавіту (кодувань кирилиці). Наприклад, в Windows використовується кодування 1251, в DOS - 866 ( "Альтернативна"), поштова кореспонденція та новини в мережі РЕЛКОМ представлені в КОІ- 8, а "стандартом" є кодування ISO 8859-5, вона ж "Основна ГОСТ". Цей список буде продовжений, якщо ми згадаємо про існування комп'ютерів Macintosh.
Природно, що при подібному різноманітті кодувань звичайна ситуація, при якій інформація на сервері БД представлена в кодуванні, відмінної від використовуваної клієнтським додатком. Наприклад, база даних в кодуванні ISO 8859-5, а клієнти під Windows (кодування 1251) і під Macintosh.
Якщо у вашій системі використовується проміжний модуль типу нашого SQLD, проблема узгодження кодувань вирішується просто. Клієнт спеціальної командою може вказувати свою кодування і кодування, в якій представлені дані, що зберігаються в базі даних. Після цього SQLD починає перекодувати "на льоту" передаються через нього запити і дані.
Після того, як демон запущений і з'єднання відкрито, SQLD опитує додаток на про ім'я та пароль користувача. У разі успішної авторизації (якщо ім'я і пароль введені правильно) демон переходить в своє основне стан, причому з цього моменту програма виконується від імені ЦЬОГО КОРИСТУВАЧА. У цьому стані SQLD дозволяє здійснити SQL-запит, виконати команду на віддаленій машині або встановити параметри перекодування.
Менеджер сеансів
Наш огляд був би не повним, якби ми не розглянули ще один підхід до побудови інформаційних систем в Internet / intranet, а саме менеджери сеансів. Ми вважаємо, що, оскільки справа йде до завершення статті, буде не зайве нагадати, що відмінною рисою інформаційних систем для Internet / intranet є використання універсального клієнтського додатка (броузера) на стороні користувача. Броузер вміє форматувати і естетично відображати на екрані HTML-файли, а так же інтерпретувати програми на мові Java. В останньому випадку універсальний клієнт наближається до "розумним" програмами, тобто програмами, відпрацьовує самостійно значну частину алгоритмів інформаційної системи. Однак, поки такі клієнти досить рідкісні, тим більше, що вони погано вписуються в існуючу зараз ідеологію Internet / intranet, яка передбачає просте і "дурне" клієнтську програму, що не вимагає настройки і обслуговування, яка допускає застосування дешевих обчислювальних засобів і не передбачає технічної підтримки . Саме ці якості і приваблюють тисячі змучених керівників інформаційних відділів у всьому світі, яким до цих пір доводиться день у день змушувати працювати відповідальні додатки під Windows.
Отже, в більшості випадків алгоритми обраховуються віддаленим сервером додатків, який управляється який-небудь потужної і стійкої операційною системою - UNIX, NT, VMS, MVS, а броузер тільки інтерпретує HTML. Значить, майже єдиним способом доступу до БД і інших ресурсів сервера залишається інтерфейс CGI, описаний на початку статті. Ви ймовірно пам'ятайте, що цей інтерфейс всім хороший, проте він не передбачає постійного з'єднання клієнта з сервером (CGI-скрипт викликається з якимось набором параметрів, відпрацьовує і завершується, повністю забуваючи про те, хто, коли і для чого його викликав). Відсутність же постійного з'єднання іноді накладає обмеження на роботу з базою даних. Наприклад, коли мова йде про курсором і високих рівнях ізоляції.
Ну що ж, якщо нам потрібні постійні з'єднання, їх можна імітувати. Для цього знову-таки треба написати проміжний модуль, який, сприймаючи запити через інтерфейс CGI або засобами Java, буде спілкуватися з сервером баз даних звичайним чином. Модулі такого роду називаються менеджерами сеансів, оскільки вони імітують сеанс зв'язку з СУБД, що має місце в традиційних системах клієнт-сервер.
Даний підхід розвивається в даний час досить бурхливо, і на ринку вже з'явилися перші комерційні системи такого роду. Може бути вам буде цікавий такий варіант: універсальний клієнт викликає CGI- скрипт, який написаний на мові Java (в даному випадку Java "живе" на сервері!), Який спілкується з менеджером сеансів, який в свою чергу через відповідну об'єктну бібліотеку спілкується з довільною СУБД.
У своїй діяльності ми поки не стикалися з необхідністю використовувати менеджер сеансів. Проте дослідницька робота такого роду запланована і наш власний менеджер буде, ймовірно, розширенням вже існуючого модуля SQLD.
Отже, ми розглянули кілька підходів до нагальну проблему: публікації баз даних в Internet / intranet. Сподіваємося, що це було корисно або цікаво. Взагалі, ця галузь програмування розвивається вкрай швидко, і через кілька місяців ситуація цілком може кардинально змінитися. Головне, що ми хотіли сказати в цій статті - публікація баз даних, що містяться під керуванням традиційних реляційних СУБД не представляє в даний час проблеми і цілком під силу прикладним програмістам. Зі свого боку, ми відкриті для співпраці.
Сергій Меліхов, Олег Бочкарьов, Олександр Куржанський, співробітники фірми DATA X / Florin. З ними можна зв'язатися за адресою [email protected]
Методи доступу до реляційних баз даних з Internet додатків
Com?А як з'єднувати Java-додаток з сервером БД?
Через CGI?