Методы доступа к реляционным базам данных из Internet приложений

Наш век называют информационным, и в последние годы масса людей уже почувствовала это, благодаря сформировавшейся коммуникационной инфраструктуре и, в немалой степени, технологии 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). Схема взаимодействия клиента и сервера строится в данном случае следующим образом:

Итак, для обеспечения доступа к серверу баз данных 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. Надеемся, что это было полезно или интересно. Вообще, эта отрасль программирования развивается крайне быстро, и через несколько месяцев ситуация вполне может кардинально измениться. Главное, что мы хотели сказать в этой статье - публикация баз данных, содержащихся под управлением традиционных реляционных СУБД не представляет в настоящее время проблемы и вполне по силам прикладным программистам. Со своей стороны, мы открыты для сотрудничества.