|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #05-06/96
|
|
Всемирная Паутина недаром так быстро завоевала широкую популярность среди пользователей Internet, в мире бизнеса, науки, политики и т. д. Основные достижения Web - это простота опубликования информации в сети, удобство и сравнительная унифицированность доступа к документам, наличие на сегодняшний день достаточно развитых средств поиска. Однако в целом способы представления, хранения и поиска информации в WWW относятся к категории информационно-поисковых систем (ИПС). Хотя хранилища данных в узлах Web иногда называют базами данных, этот термин в данном случае можно использовать только в самом широком смысле. Исторически ИПС применялись для хранения слабоструктурированной и редко изменяемой информации. Базы данных в узком смысле - это хранилища структурированной, изменяемой информации, причем информация в базе данных должна всегда находиться в согласованном состоянии.
Замечание: везде далее мы предполагаем знакомство читателя с терминами Internet и их смыслом в объеме цикла статей Павла Храмцова. Почти все они опубликованы в различных изданиях "Открытых систем", а также в виде отдельной книжки (скоро выйдет вторая; рекомендую).
На наш взгляд, Web - это популистское развитие идей ИПС, базирующееся на развитых возможностях Internet. С равным успехом можно хвалить и ругать Web. Можно хвалить Всемирную Паутину за то, что, не выходя из дома, вы можете побывать в любой точке земного шара и посмотреть, что же там происходит. Можно ругать Web за то, что трудно найти действительно актуальную информацию (обычно она устаревшая), за то, что хранилища информации содержат очень много "мусора", опубликованного непонятно из каких соображений. (Недавно мне пришло в голову просмотреть "Желтые Страницы Internet". Впечатление отталкивающее. Такое чувство, что ребята просто развлекаются. "Дзен-буддизм и Internet", плохие картинки на телеконференции, множество вариантов квакания - конечно же, лягушек - для отображения на платформах SPARC и т. д.) Но в любом случае интерфейс действительно удобен.
Ситуация с базами данных кардинально отличается. Именно базы данных содержат основные знания человечества. В конце двадцатого века с появлением технологии баз данных мы накопили больше информации, чем за всю предыдущую историю. Вся беда в том, что доступ к базам данных (даже к тем, которые содержат полностью открытую информацию) ограничен. Чтобы получить интересующую его информацию, пользователь должен иметь физический доступ к соответствующей СУБД, быть в курсе модели данных, знать схему базы данных и, наконец, уметь пользоваться соответствующим языком запросов. Что касается языка запросов, то проблему частично решает протокол ODBC, позволяющий направлять ограниченный набор операторов SQL (с промежуточной обработкой соответствующим драйвером ODBC) к произвольному серверу баз данных. Но это только частичное решение, поскольку оно никак не помогает пользователю понять схему базы данных (даже в терминах SQL) и, конечно, не способствует созданию унифицированного интерфейса конечного пользователя (нельзя же заставить всех работать в строчном режиме на языке SQL).
Итак, что же мы имеем. Мы имеем удобные средства разработки распределенных в Internet гипермедийных документов, простые, удобные, развитые и унифицированные интерфейсы для доступа к информации WWW. Кроме того, мы имеем большое количество ценных баз данных, управляемых разнородными СУБД, а также желание сделать эти базы доступными всем людям (в случае публичных баз данных) или членам территориально-распределенной корпорации (в случае корпоративных баз данных). Возникает естественное желание скрестить эти две технологии и обеспечить доступ к базам данных в интерфейсе Web. Еще два года назад существовали только идеи такого скрещивания и не очень тщательно разработанные подходы к реализации. На сегодняшний день имеется несколько работающих механизмов, и далее мы их обсудим. В целом механизмы делятся на два класса: обеспечивающие доступ к базе данных (по запросу клиента) на стороне Web-сервера и работающие непосредственно на стороне клиента.
Механизм реализуется за счет наличия двух более или менее стандартизованных средств: возможности включения форм в документ, составленный с использованием языка гипермедийной разметки HTML, и возможности использования внешних по отношению к серверу Web программ, взаимодействие которых происходит через специфицированный протокол CGI (Common Gateway Interface) или внедренный позже API (Application Program Interface). (Хотя CGI называется "общим интерфейсом шлюзования", по сути дела, это одновременно некоторое подмножество протокола HTTP, и способ его соблюдения при взаимодействии сервера с внешней программой.)
При реализации на основе CGI общая схема реализации доступа к базе данных на стороне Web-сервера выглядит следующим образом:
Замечание: говоря формально, внешняя программа осуществляет компиляцию языка форм в базовый язык сервера баз данных; это может быть очень простая компиляция с использованием заготовок SQL-операторов, но тем не менее компиляция. Между прочим, многие люди недооценивают сложность этой проблемы. Компилятор он и в Африке компилятор. Язык форм ничем не проще любого другого языка. Толмач - это наиболее ценный элемент нашего разрозненного общества. Как мне смешно, когда некоторые мои знакомые считают, что перевести запрос, заданный на языке форм, в представление на языке SQL проще, чем откомпилировать программу на языке Фортран в машинные коды;
На сленге Web-мастеров любая внешняя программа, запускаемая Web-сервером в соответствии со спецификациями CGI, называется CGI-скриптом. CGI-скрипт может быть написан на языке программирования (Си, Си++, Паскаль и т. д.) или на командном языке (языки семейства shell, perl и т. д.). CGI-скрипт, выполняющий роль посредника между Web-сервером и другими видами серверов (например сервером баз данных), называется шлюзом (видимо, более правильно было бы использовать термин CGI-шлюз). Наличие CGI-скриптов на стороне Web-сервера позволяет, в частности, перенести часть логики приложения из клиента в сервер. CGI-шлюзы представляют собой средство для организации трехзвенной (в общем случае, многозвенной) архитектуры клиент-сервер.
В спецификациях CGI предусмотрены четыре способа взаимодействия Web-сервера и CGI-скрипта (по крайней мере в среде ОС Unix). Первый способ состоит в использовании создаваемых сервером переменных окружения, через которые передается как общая информация, независящая от функциональных особенностей CGI-скрипта (например имя и версия Web-сервера), так и специфические данные, определяющие поведение CGI-скрипта (скажем набор значений, введенных в форму на стороне клиента). Второй способ заключается в формировании параметров argc и argv, которые передаются функции main CGI-скрипта (как если бы CGI-скрипт вызывался командной строкой в интерактивном режиме). Этот способ применяется для реализации ограниченного класса запросов ISINDEX. Наконец, входные параметры могут передаваться CGI-скрипту через файл стандартного ввода, а CGI-скрипт может передавать Web-серверу результирующие данные через файл стандартного вывода.
Как видно, при использовании CGI вся интерпретация пользовательского запроса производится CGI-скриптом. Скрипт может быть предельно жестким, ориентированным на выполнение запроса к фиксированной таблице фиксированной базы данных, или относительно гибким, способным выполнить произвольный запрос к одной или нескольким таблицам базы данных, идентифицируемой в параметрах клиента.
Что касается API, то для людей, знающих одновременно Unix и операционные системы вообще, ситуация предельно ясна. Запуск независимого "тяжеловесного" процесса стоит немало. Загрузка и выполнение еще одной программы в уже существующем адресном пространстве по сравнению с предыдущем вариантом гораздо дешевле. Нет никаких новых идей. API - это, фактически, дешевый способ (хотя и небезопасный: понятно, почему?) выполнить в адресном пространстве сервера WWW программу, которая соответствует спецификациям на языке HTML (объясняю, почему; никто не захочет впустить в свою квартиру на предмет хотя бы временного жительства незнакомого человека; внешние программы незнакомы серверу). Такая программа должна быть заранее подготовлена и включена в библиотеку, из которой сервер может производить динамическую загрузку (например такая библиотека может быть разделяемой - shared library). Т. е. смысл не меняется, меняется только реализация.
Видимо, наиболее мощные средства обеспечения доступа к базам данных на стороне Web-клиента обеспечивает язык Java. Java - это объектно-ориентированный язык программирования, являющийся, по сути дела, "безопасным" подмножеством языка Си++. В частности, Java не содержит средств адресной арифметики, не поддерживает механизм множественного наследования и т. д. Поэтому утверждается, что корректность Java-программы можно проверить до ее реального выполнения (это абсолютно недоказанное утверждение). Различают:
Для обеспечения доступа к базам данных на стороне Web-клиента наиболее существенно наличие языка Java. Технология разработки HTML-документа позволяет написать произвольное количество дополнительных Java-программ, откомпилировать их в мобильные коды и поставить ссылки на соответствующие коды в теле HTML-документа. Такие дополнительные Java-программы называются апплетами (Java-applets). Получив доступ к документу, содержащему ссылки на апплеты, клиентская программа просмотра запрашивает у Web-сервера все мобильные коды. Коды могут начать выполняться сразу после размещения в компьютере клиента или быть активизированы с помощью специальных команд.
Поскольку апплет представляет собой произвольную Java-программу, то, в частности, он может быть специализирован для работы с внешними базами данных. Более того, система программирования Java включает развитый набор классов, предназначенных для поддержки графического пользовательского интерфейса. Опираясь на использование этих классов, апплет может получить от пользователя информацию, характиризующую его запрос к базе данных, в том же виде, как если бы использовался стандартный механизм форм языка HTML, а может применять какой-либо другой интерфейс.
Для взаимодействия Java-апплета с внешним сервером баз данных разработан специализированный протокол JDBC, который, фактически, сочетает функции шлюзования между интерпретатором мобильных Java-кодов и ODBC, а также включает ODBC.
В заключение сравним достоинства и недостатки двух рассмотренных подходов. Использование CGI-скриптов на стороне Web-сервера позволяет иметь на стороне клиента только сравнительно простые программы просмотра. Вся хитроумная логика работы с базами данных (возможно, с обработкой полученных данных) переходит на сторону Web-сервера. Это легкий способ построения трехзвенной архитектуры приложения. (В последнее время разгрузку клиента от логики приложения называют решением проблемы "толстого" клиента. В данном случае мы можем иметь предельно тонкого клиента при утолщении сервера.) Отрицательным моментом является то, что при необходимости подключения нового CGI-скрипта, вообще говоря, требуется (относительная) модификация кода сервера.
Использование Java-апплетов, вообще говоря, обеспечивает более гибкое решение. Апплет - это часть HTML-документа. Для включения нового апплета нужно всего-навсего перекомпоновать документ. Web-сервер трогать не нужно. С другой стороны, клиент должен быть толще. Что бы там не говорили, клиент должен быть достаточно "толстым", чтобы в приемлемое время справиться с интерпретацией всех апплетов. Но, конечно же, сервер по-прежнему должен быть "толще" клиента.
На самом деле и при применении первого подхода, и при использовании второго остается нерешенной одна организационно-производственная проблема: кто должен проектировать, писать, отлаживать и сопровождать процедурный код? Web-мастера, производящие HTML-документы, обычно считают себя, скорее, дизайнерами нежели программистами. А здесь требуется чисто программистская работа. Иметь же двух мастеров на одном Web-site - это недопустимая роскошь. Придется растить людей, обладающих достаточными эстетическими способностями и являющимися в то же время квалифицированными и ответственными программистами. Я всегда говорил, говорю и говорить буду, что для этого нужно хорошо платить. Это единственное экономически оправданное решение.
А вообще-то, если хорошо разобраться, во всей Web-технологии нет ничего нового. Дал бы Бог придумать что-то, сочетающее черты гипертекста, так любимого пользователями, и баз данных, предназначенных для хранения не мусорной, а действительно ценной информации. Я лично попробую, хотя и ничего не обещаю. Возможно, нужно зацепиться за сравнительно новый, но уже весьма популярный термин "универсального сервера баз данных". Даешь новый, удобный и развитый интерфейс интегрированных информационных систем!
|
|