Эсперанто для баз данных

Разработчики баз данных торопятся утолить повышенный спрос на рынке корпоративных сетей Intranet. Технология JDBC компании JavaSoft имеет все шансы стать своеобразным эсперанто этого растущего сектора рынка.

ПОСТАВЛЯЕМЫЕ ДРАЙВЕРЫ JDBC
Ресурсы JDBC

И НА JAVA, И НА JDBC ЕСТЬ ПЯТНА
Технические замечания и системные премудрости

Аналитики предсказывают в ближайшие несколько лет бурный рост рынка Intranet. На приложения для этих сетей будет истрачено в четыре раза больше средств, чем для приложения Internet. По оценкам Forrester Research, в 1999 году суммарные затраты на Intranet и Internet превысят 9 млрд. долларов.

Однако чтобы заставить технологию Intranet работать в полную силу, нужен язык программирования, с помощью которого компании могли бы приспособить под свои конкретные задачи приложения для внутрикорпоративных сетей. Главное, что этот язык должен иметь средства доступа к базам данных. "Бурный рост Internet и Intranet рождает необходимость в протоколе баз данных, способном обеспечить клиент-серверные СУБД характерными для сегодняшних приложений в архитектуре клиент-сервер функциональными возможностями и удобством использования", - сказал Боб Перро, вице-президент по разработкам Visigenic.

На эту роль есть серьезный претендент. Язык Java, разработанный подразделением Sun Microsystems, компанией JavaSoft, обладает всеми необходимыми качествами, чтобы стать (если этого до сих пор не случилось) своеобразным эсперанто для этого сектора рынка. Благодаря своему интерфейсу Database Connectivity API, Java позволяет обращаться к базам данных на естественном языке.

ПРЕДЫСТОРИЯ JDBC

Первая версия Java не имела вообще никаких средств работы с базами данных, что давало повод к справедливым сомнениям в необходимости языка вообще. Однако вскоре JavaSoft опубликовала предварительный стандарт интерфейса прикладного программирования для баз данных под названием Java Database Connectivity (JDBC). В окончательную версию языка, Java 1.1, включена поддержка спецификации JDBC.

"Современные решения для Internet и Web предполагают работу с приложениями, которые поддерживают статичные тексты и графику, - поясняет Перро. - Java обогащает Internet интерактивными приложениями, но до сих пор этот язык не имел встроенных средств взаимодействия с базами данных. Теперь же, при помощи новых продуктов, через Internet можно обращаться к хранящейся в базах данных корпоративной информации. Доступ контролируется непосредственно логикой приложений Java, таким образом, он больше не зависит от статичного представления данных в формате HTML, как это было в пору медленных серверов CGI".

JDBC представляет собой стандартный интерфейс доступа к базам данных SQL. Компания обнародовала версию 1.0 JDBC API в июне 1996 года. Версия 1.1, распространяемая сейчас, входит в комплект Java Developer's Kit 1.1. Программное обеспечение JDBC API предоставляет программистам на Java единый интерфейс доступа к многочисленным реляционным базам данных и общую платформу для разработки высокоуровневых приложений и интерфейсов. Ведущие производители баз данных, средств доступа и инструментов уже взяли JDBC на вооружение и применяют его при разработке своих продуктов. Многие предлагают драйверы JDBC для организации взаимодействия Java с разнообразными СУБД (электронные адреса производителей перечислены в таблице "Ресурсы JDBC").

ПОЙМАННЫЕ ОДНОЙ СЕТЬЮ

Подключение базы данных к Intranet сулит массу преимуществ. Эти преимущества столь велики, что некоторым менеджерам по разработке они видятся просто безграничными - конечно, в пределах отведенного бюджета. Первое же приложение, разработанное одним из таких неофитов менее чем за месяц, открыло членам его группы доступ к необходимой им для работы основной базе данных.

Тех же, кто хочет получить дополнительное подтверждение технологических и финансовых преимуществ модели Intranet по сравнению с традиционной клиент-серверной, можно отослать к опыту многочисленных администраторов, имевших дело даже с достаточно удачными проектами систем в архитектуре клиент-сервер. По их мнению, разработка таковых слишком часто оканчивается плачевно. Опубликованные результаты исследований свидетельствуют, что более 50% проектов разработки клиент-серверных систем либо не увенчались успехом, либо были закрыты до окончания работ, либо оказались попросту заброшены. Часто произведенное в рамках таких проектов ПО не имело важных функциональных возможностей. Нередко случалось и так, что бизнес-процессы успевали настолько измениться за время разработки, что созданный продукт оказывался совершенно бесполезным.

Разумеется, опыт применения приложений на базе Intranet еще слишком мал для серьезных статистических исследований, однако уже сейчас можно привести некоторые соображения в пользу приложений на базе Java. Так, например, Ян Кемпбелл, директор по сотрудничеству и Intranet в International Data Corp. (IDC) провел исследование предварительных данных об окупаемости (Returns on Investment, ROI) для шести ведущих корпораций. Подводя итоги работы, он сказал: "Предварительные данные анализа ROI для внутрикорпортивных сетей Netscape показывают, что стандартная окупаемость составляет 1000% - намного больше, чем при вложениях в любую другую технологию". Кроме того, затраты окупаются всего за 6-12 недель, а значит, проекты Intranet менее рискованны.

Офер Бен-Шакар, председатель совета директоров и исполнительный директор по технологиям компании NetDynamics, выделил три основных достоинства JDBC. Во-первых, JDBC - это не что иное, как Java; другие решения для взаимодействия с базой данных предполагают привлечение механизмов C++. Во-вторых, JDBC переносим между базами данных; для перехода, например, с SQL Server на Informix требуется немного исправить (или не исправлять вовсе) код приложения. И, наконец, в-третьих, все основные производители баз данных уже поддерживают или в скором времени будут поддерживать JDBC.

КОГДА ЧЕЛОВЕК НЕ ЗНАЛ КОФЕ

Даже поверхностный взгляд на генеалогию JDBC натыкается на API. В 1969 году Е. Ф. Кодд опубликовал свою модель данных, указав на связь между хранимой информацией, или базой данных, и теорией множеств. В 70-х и начале 80-х годов Кодд с группой исследователей, к которым вскоре присоединились IBM, Oracle и другие компании, развили эти представления и разработали первую систему управления реляционной базой данных (СУРБД).

К сожалению, большинство разработчиков "продвигали" собственные разновидности языка SQL, или Structured Query Language, для выборки и обработки данных из реляционной базы данных. Это естественным образом привело к тому, что пользователи и администраторы баз данных оказались привязаны к продуктам, которые случилось купить их компаниям. Предвидя грядущий хаос, производители во главе с ANSI и впоследствии ISO стандартизировали в 1986 году SQL. Спустя шесть лет, в 1992 году, стандарт был пересмотрен.

Увы, но даже в новой редакции стандарт ANSI слишком абстрактен для коммерческого применения. Он определяет 13 основных предложений SQL, в том числе Select, Update и Create Table, и не описывает способа взаимодействия СУБД и приложений. Для стандартизации интерфейса производители сформировали группу SQL Access Group (SAG) и определили интерфейс Call Level Interface (CLI), благодаря которому приложения могут обращаться к базам данных без использования SQL. Этот интерфейс предоставляет библиотеку функций, которые могут быть собраны и вызваны в реальном времени, в результате приложение имеет возможность использовать и обновлять данные, хранимые в базе.

ODBC: ПРЕДВЕСТНИК JAVA

В 1992 году в результате работы этих групп наконец-то появилось то, что позднее стало популярной, нашедшей широкое применение технологией Open Database Connectivity (ODBC) API компании Microsoft. В своей реализации Microsoft применила спецификации CLI группы SAG, разделив их на два компонента: диспетчера ODBC и драйвера ODBC.

Первый предлагал единый интерфейс всем приложениям, нуждающимся в доступе к базе данных. Это достигалось благодаря полному, достаточно сложному набору функций, с помощью которых программы могли выполнять все задачи, связанные с СУБД - запросы, добавления и обновления данных, исполнение хранимых процедур, а также обращение к источнику данных с просьбой представить описание самого себя. Интерфейс администратора ODBC оставался одинаковым независимо от того, с какой СУБД, приложение взаимодействовало.

Другой же компонент, драйвер ODBC, напротив, зависел от СУБД. Диспетчер использовал драйверы для преобразования запросов на обслуживание от приложений в запросы на языке базы данных. В последних версиях ODBC-продуктов архитектура достигла логического завершения в виде единственного универсального драйвера, работающего на клиентских машинах. Он взаимодействует с диспетчером на сервере, а тот в свою очередь использует специфический драйвер СУРБД. Это усовершенствование стало значительным шагом вперед, поскольку конфигурация драйвера на клиенте была весьма сложной и трудоемкой задачей. Благодаря новой архитектуре достаточно проделать всю работу один раз на сервере, а не выполнять ее снова и снова на каждом клиенте.

JDBC во многом опирается на опыт разработчиков ODBC. Прикладной интерфейс реализован как набор классов Java и позволяет программисту на Java подавать запросы SQL, а также обрабатывать результаты их выполнения внутри апплета или приложения Java. Как и в ODBC, разработчики реализуют JDBC API посредством диспетчера драйверов, а он в свою очередь поддерживает многочисленные драйверы, осуществляющие связь с различными базами данных. Драйверы JDBC можно либо полностью написать на Java, чтобы загружать как часть апплета, либо разработать естественными средствами, чтобы построить мост к существующим библиотекам доступа к базе данных.

В сущности первым коммерческим продуктом на базе JDBC был простой драйвер моста от JDBC к ODBC, разработанный совместно компаниями JavaSoft и InterSolv. В самом термине "драйвер моста" содержится ссылка на метод, которым вызовы JDBC на сервере передаются - практически без изменений - стандартному драйверу ODBC. Благодаря наличию моста, JDBC может использовать те средства взаимодействия с базой данных, которые предоставляют имеющиеся драйверы ODBC. Структура JDBC позволяет эффективного реализовывать JDBC поверх ODBC, поэтому мост между JDBC и ODBC - наилучший способ использования ODBC из Java.

Хотя предметом нашей статьи является взаимодействие JDBC с реляционными базами данных, нельзя не отметить, что JDBC API не ограничен только одним конкретным типом хранилищ постоянных данных. Если наделить реализацию драйвера JDBC необходимыми функциональными возможностями, этот интерфейс можно будет использовать для связи с такими несхожими источниками информации, как аудио, видео и другие мультимедийные типы, а также нереляционными базами данных.

Важнейшим событием в области JDBC в этом году должно стать появление высокоуровневых компонентов со встроенным JDBC API. Конкурирующие инструменты программирования содержат компоненты, предлагающие аналогичные функциональные возможности. Например, Visual Basic компании Microsoft предоставляет Data Access Objects и Remote Data Objects как в управляющих формах OLE, так и API. При создании не очень сложных приложений программисты используют управляющие формы OLE, которые можно перетащить из панели инструментов на отображаемую форму; те же, кто хочет создать приложения с более изощренными средствами манипулирования данными, пользуются формами API.

ПОДНОГОТНАЯ JDBC

Все драйверы JDBC можно разделить на четыре категории: мост от JDBC к ODBC; драйвер частично на Java с оригинальным API; драйвер полностью на Java с сетевым протоколом; и, наконец, драйвер на Java с оригинальным протоколом.

Мост от JDBC к ODBC обеспечивает доступ с помощью драйверов ODBC. Стоит заметить, что для этого нужно загрузить некие двоичные коды ODBC и в большинстве случаев клиентскую программу базы данных на каждую клиентскую машину, где используется этот драйвер. Таким образом, мост более всего подходит для корпоративной сети или сервера приложений, написанного на Java, с трехзвенной архитектурой.

Драйвер частично на Java с оригинальным API преобразует вызовы Java в клиентский API для Oracle, Sybase, Informix, DB2 и других СУБД. Подобно всем драйверам моста, драйверы этого типа предполагают загрузку некоего двоичного кода на каждой клиентской машине.

Драйвер полностью на Java с сетевым протоколом преобразует вызовы JDBC в независящий от СУБД сетевой протокол, который далее на сервере преобразуется в протокол СУБД. Это сетевое серверное промежуточное программное обеспечение связывает все клиенты Java с различными базами данных; конкретный протокол СУБД зависит от производителя. Как правило, такой драйвер является наиболее гибким вариантом JDBC. Производители, реализующие это решение, способны, пожалуй, предлагать и продукты для Intranet. Чтобы такие продукты поддерживали и доступ через Internet, поставщики должны предусмотреть поддержку защиты, возможность доступа через брандмауэры и т. д. Некоторые, например, IBM, Sybase и Informix, включают драйверы JDBC в промежуточное программное обеспечение для своих баз данных. В драйверах такого рода часто используют драйверы ODBC на сервере для реального взаимодействия с СУБД.

Драйвер полностью на Java с оригинальным протоколом непосредственно преобразует вызовы JDBC в сетевой протокол, который данная СУБД использует. Этот подход позволяет направлять вызовы с клиентов непосредственно на сервер СУБД. Такое решение имеет практический смысл, если конфигурация клиентов контролируется достаточно жестко, как это и бывает в типичных приложениях для Intranet. Поскольку большинство протоколов для баз данных нестандартны, драйверы этого типа должны поставлять сами производители.

В API С ГОЛОВОЙ

Логически взаимосвязанные классы Java объединены в пакеты; пакет JDBC называется java.sql. В пакете классы сгруппированы в интерфейсы. Каждый интерфейс предоставляет набор переменных и методов, которые апплеты и приложения Java могут вызывать. Совокупность переменных представляет собой состояние, или текущие условия, либо данного логического пакета, либо интерфейса; методы не определяют диапазон поведения и действия, которые пакет или интерфейс могут выполнить. Пакет java.sql имеет следующие интерфейсы: Driver, Connection, Database-MetaData, Statement, PreparedStatement, CallableStatement, ResultSet и ResultSetMetaData. Кроме того, java.sql включает в себя классы Date, Time и Timestamp, DriverManager, DriverPropertyInfo и Typеs, а также исключительные ситуации DataTruncation, SQLException и SQLWarning.

Интерфейс Driver включают оба компонента: драйвер и диспетчер драйверов. При активизации драйвера его метод getConnection связывается с базой данных и обращается к объекту соединения. Последний может участвовать только в одном сеансе с базой данных, поэтому, если программа хочет получить доступ, например, к двум базам данных Informix, каждая из них должна иметь свой объект соединения. Тот же, кто планирует обращаться из программы к нескольким базам, должен будет загрузить несколько драйверов или создать несколько объектов соединения.

Интерфейс Connection представляет сеанс с конкретной базой данных и является главным компонентом пакета JDBC. Интерфейс предназначен для подачи и возвращения результатов команд SQL. Методы соединения commit, rollback и setAutoCommit управляют транзакциями, а объекты CallableStatement, создаваемые методом CreateStatement интерфейса Connection, - хранимыми процедурами. Интерфейс Connection можно использовать и для предоставления советов базе данных с целью оптимизации запросов.

Для получения информации интерфейс Connection использует метод getMetaData, который возвращает объект DatabaseMetaData. Он предоставляет информацию с описанием таблиц базы данных, поддерживаемую ею грамматику SQL, ее хранимые процедуры, возможности соединения и т. д.

Интерфейс DatabaseMetaData запрашивает у базы данных информацию о ней самой. Вы можете с успехом писать программы, "не знающие" практически ничего о базе данных, к которой обращаются. Интерфейс DatabaseMetaData позволяет приложениям извлекать необходимую информацию в реальном времени (при условии, что пользователь имеет соответствующие права на выполнение заданий), благодаря чему можно получать мелкие, но важные подробности, например, какой символ используется в качестве разделителя и как СУБД обрабатывает значение Null при сортировке.

Три интерфейса - Statement, PreparedStatement и CallableStatement -предоставляют приложению или апплету средства, с помощью которых собственно приложение и передает команды SQL базе данных. Statement and PreparedStatement очень похожи: они различаются только тем, сколько раз используется SQL: один или несколько. CallableStatement применяется для исполнения набора команд SQL, хранимых в базе данных.

Как Statement, так и PreparedStatement применяются, когда требуется передать базе данных команды для исполнения. При этом база данных создает многочисленные различные планы для удовлетворения нового запроса. (В конце концов, SQL - это логический язык, предоставляющий множество способов выборки данных из физического хранилища.) После создания планов оптимизатор базы оценивает их и выбирает наиболее эффективный, который далее компилируется в двоичное представление. Приложение же получает указатель или метку этой двоичной версии. Существенное различие между Statement и PreparedStatement в том, что Statement не сохраняет этой метки, а PreparedStatement сохраняет, так что проделанная работа не пропадает втуне, и ее результаты могут быть использованы повторно. Предусмотрительный разработчик непременно воспользуется этим немаловажным преимуществом.

Как, впрочем, и многопоточными возможностями Java. Поскольку JDBC работает по последовательному принципу (т. е. очередной команде программы приходится ждать, пока не выполнится другая), сокращение задержки при обработке длинных задач (например, выполнение запросов SQL) за счет создания нескольких потоков может оказаться весьма кстати.

Интерфейс CallableStatement выполняет хранимые процедуры SQL. Эта возможность, зачастую незамечаемая досужими обозревателями, крайне важна, поскольку в большинстве организаций активные команды SQL (Insert, Update, Delete) запрещены для прямого использования. JDBC (как и весь Java) - средство объектно-ориентированное, что означает простоту задания параметров и получения результатов. Таким образом, исполнение хранимых процедур (которые возвращают набор из нескольких результатов) в случае JDBC гораздо проще, чем в случае многих других сред, например Visual Basic.

Наборы из нескольких результатов часто используют при разработке стратегии выборки данных, отвечающих объектно-ориентированной структуре (некоторые атрибуты объекта могут быть реализованы как совокупности самих объектов, например объект СТУДЕНТ может иметь атрибут, содержащий совокупность курсов, на которые некий студент записался или окончил). Кроме того, такие множества применяются для разработки стратегий выборки данных, имеющих целью минимизацию числа запросов за счет прогнозирования дополнительной потребности в данных (например, в поиске всех заказов данного клиента после нахождения самого клиента).

Интерфейс ResultSet представляет собой курсор - иными словами, совокупность строк, выбранных базой данных по запросу. Поскольку апплеты или приложения, как правило, обрабатывают одновременно только одну строку (или ограниченное число строк, которые выдаются в виде таблицы или решетки), курсор представляет собой средство "удержать" все множество выданных строк, а также и указатель на множество. Когда один из объектов интерфейса Statement исполняет запрос, возвращаемым значением будет ResultSet. Только захватив этот результат, приложение получает возможность действительно предоставить пользователю информацию.

Некоторые технологии промежуточного программного обеспечения, такие как оригинальные драйверы или ODBC-драйверы, поддерживают курсоры с полной прокруткой, т. е. апплет может перемещать указатель текущей строки в любом направлении. Тем не менее JDBC поддерживает лишь прокрутку вперед. Апплеты, которым необходима возможность перемещаться по множеству результатов в обоих направлениях, необходимо моделирование обратного направления. Это достигается путем повторного обращения к базе данных и прохода вперед посредством вызова следующего метода ResultSet до того места, которое требуется просмотреть. Это серьезный недостаток. Хотелось бы, чтобы он был преодолен как можно скорее.

Интерфейс ResultSetMetaData позволяет получить информацию о типах и свойствах столбцов в ResultSet. Эта возможность особенно важна при построении динамических систем, таких как среда разработки или инструментарий для написания запросов, когда база данных и ее структуры неизвестны заранее.

ТОЛЬКО НАЧАЛО

Язык, претендующий на звание языка общего назначения, должен обладать функциональными возможностями для связи с базами данных и манипуляции с извлеченными из них данными. Java в этом смысле не исключение. Технология JDBC прошла сложный путь до хорошо реализованного, удобного в применении средства менее чем за год. На первый взгляд такой темп слишком высок, но только на первый взгляд, так как его диктует эпоха Internet.

JDBC, бесспорно, есть в чем совершенствоваться (см. врезку "Технические замечания и системные премудрости", где коротко перечисляются еще нерешенные вопросы). Однако если учесть скорость, с которой теперь на рынок поставляются работоспособные продукты, и в буквальном смысле жадность, с которой пользователи "расхватывают" их, у JDBC прекрасные перспективы.

ПОСТАВЛЯЕМЫЕ ДРАЙВЕРЫ JDBC

Ресурсы JDBC

Дополнительную информацию по Java и JDBC можно получить по следующим адресам.

www.agave.com
JDBC NetServer компании Agave Software Design - драйвер типа 3.

www.gamelan.com
Gamelan - домашняя страничка с информацией о ресурсах Java; она содержит крупную коллекцию апплетов.

www.intersolv.com
Компания InterSolv - ведущий производитель средств ODBC и JDBC, а также участник разработки моста от JDBC к ODBC.

www.javasoft.com
Домашняя страница компании JavaSoft.

www.javasoft.com/jdbc/index.html
Страница Web-узла JavaSoft, посвященная JDBC.

www.javaworld.com
JavaWorld - интерактивный журнал сообщества разработчиков Java.

И НА JAVA, И НА JDBC ЕСТЬ ПЯТНА

Технические замечания и системные премудрости

Техническое замечание 1: Internet Explorer

Internet Explorer 3.0 корпорации Microsoft не всегда корректно исполняет апплеты Java, особенно если они используют JDBC. В статье "Knowledge Base" на узле Web компании Microsoft (www.microsoft.com/kb/articles/q155/1/63.htm) есть предупреждение, что у Explorer 3.0 возникают иногда проблемы при загрузке байт-кодов Java. Microsoft предлагает некую уловку, которая якобы позволяет выйти из положения, - отключить компилятор Java Just In Time. Увы, не помогает. Остается только надеяться, что в версии Internet Explorer 3.01 проблема будет решена.

Техническое замечание 2: защищенное взаимодействие с JDBC

По соображениям безопасности, стандартная реализация Java в браузере предполагает, что загружаемые по сети апплеты (в том числе и те, что используются для JDBC) устанавливают соединение только с той машиной, с которой апплет был загружен. На практике это означает, что серверный компонент JDBC должен работать на той же машине, что и сервер Web. Иначе говоря, конфигурацию системы для работы с JDBC придется серьезно обдумывать. С другой стороны, если браузер загрузил апплет из локального файла, он проверит, хранится ли тот в папке, входящей в переменную среды Classpath. Если да, то этот апплет получит разрешение на проведение таких операций, как установление сетевых соединений с другой системой. В противном случае к апплету будут применены те же ограничения по защите, что и к загруженному по сети. В частности, браузер получит возможность установить сетевое соединение только с локальной системой, поскольку это машина, с которой он загружался.